First Edition. BachelorPraktikum. Hinweise für Teilnehmer. Dr. Michael Eichberg Johannes Lerch Joscha Drechsler

Größe: px
Ab Seite anzeigen:

Download "First Edition. BachelorPraktikum. Hinweise für Teilnehmer. Dr. Michael Eichberg Johannes Lerch Joscha Drechsler"

Transkript

1 First Edition BachelorPraktikum Hinweise für Teilnehmer Dr. Michael Eichberg Johannes Lerch Joscha Drechsler

2 Bachelor-Praktikum 1 Die wesentlichen Elemente des Bachelor-Praktikums am Fachbereich Informatik der Technischen Universität Darmstadt Dr. Michael Eichberg (Redaktion) (Gesamtverantwortung) Johannes Lerch (Organisation und Ablauf) Joscha Drechsler (Organisation und Ablauf)

3 Vorwort Das folgende Dokument beschreibt die wichtigsten Aspekte rund um das Bachelor-Praktikum des Fachbereichs Informatik der Technischen Universtität Darmstadt. Es dokumentiert insbesondere auch Erkenntnisse sowie Antworten auf Fragen, die im Laufe der Jahre aufgekommen sind. Das Dokument ist deswegen ein lebendes Dokument, das der ständigen Weiterentwicklung unterliegt. ii

4 Section 1 Struktur Das Bachelor-Praktikum des Fachbereichs Informatik der Technischen Universität Darmstadt gliedert sich auf in zwei Lehrveranstaltungen: Bachelor-Praktikum Ein Praktikum des Fachbereichs Informatik, bei dem über ein Zeitraum von 6 Monaten eine umfangreiche(re) Aufgabenstellung in einem Team von vier Studierenden bearbeitet wird. Die Aufgabenstellungen werden von den Fachgebieten der Technischen Universität Darmstadt gestellt. Die Organisation und fachliche Betreuung erfolgt durch den Fachbereich Informatik. Das Bachelor-Praktikum ist verpflichtend für Bachelor-Studierende des Studienganges Bsc Informatik. Bachelor-Praktikum (6CP) Projektbegleitung Projektbegleitung (3CP) Die Projektbegleitung ist eine integrierte Lehrveranstaltung zur Begleitung des Bachelor-Praktikums. Die Projektbegleitung ergänzt die Kanonik Einführung in Software Engineering und dient der Vermittlung / Wiederholung von Kenntnissen, die notwendig sind für die systematische Softwareentwicklung. Insbesondere wird auf die Darstellung von hilfreichen Werkzeugen zur Durchführung von Software Engineering Projekten eingegangen. Einen weiteren Schwerpunkt bildet die Erstellung des Qualitätssicherungsdokuments. Darüber hinaus werden im Rahmen der Projektbegleitung die Projektthemen durch die Studierendengruppen präsentiert. 3

5 Section 2 Ablauf Projektbegleitung (Sommersemester 14) Opt-in Deadline für Supervision Vorstellung HDA; QS-Dokument Tools Bachelor-Praktikum Start - jetzt D.h. der Teamleiter wird sich (sehr zeitnahe) bei seinen Gruppen melden, um ein erstes Treffen zu vereinbaren. Gemeinsam mit dem Teamleiter wird dann ein Treffen mit dem Auftraggeber vereinbart. (im Normalfall im Laufe der nächsten Woche; spätestens jedoch übernächste Woche) Ende Abgabe aller Dokumente und Beendigung der Implementierung (Dieser Termin ist strikt und unter keinen Umständen verhandelbar.) Anfang/Mitte Mai Abgabe der Vorversion der Qualitätssicherungsdokumente (Datum vorgegeben durch Teamleiter.) (Deckblatt + max. 2 Seiten; behandelt ausschließlich die Sicherung der Qualität des Codes) Besprechung der Vorabgaben der Qualitätssicherungsdokumente Tools , Projektbegleitungsvorlesung entfällt (HDA) 4.7., Präsentation der Projekte (Anwesenheit aller Teilnehmer ist gefordert) Mitte Juni/Anfang Juli - Abgabe der QS-Dokumente Abschluss der Projektbegleitung 4

6 Section 3 Abgaben Agiler Softwareentwicklungsprozess Sollte der agile Softwareentwicklungsprozess gewählt werden, dann sind folgende Artefakte abzugeben. Im Folgenden wird beschrieben welche Artefakte am Ende des Projektes abzugeben sind. Die Art der Dokumente, die abzugeben sind, richtet sich nach dem gewählten Softwareentwicklungsprozess und ist im Folgenden beschrieben. Das Dokumentenformat muss in allen Fällen PDF sein. Über die im Folgenden genannten Artefakte hinaus sind keine weiteren Dokumente (insbesondere kein Sourcecode oder vergleichbares) bei der Projektbegleitung abzugeben. Prozessunabhängig " Qualitätssicherungsdokument " Anhang zum Qualitätssicherungsdokument " User Stories bzw. erfasste Anforderungen " (ggf. Anhang zu den User Stories) Unified Process In diesem Fall ist ein Pflichtenheft zu erstellen, dass vom Auftraggeber abgenommen werden muss und alle wesentlichen Abschnitte aufweisen muss. Für die weiteren Details nehmen Sie bitte Kontakt zur Projektbegleitung auf. Am Ende des Projektes ist immer ein Projekttagebuch abzugeben. Dies gilt auch dann, wenn das Projekttagebuch leer ist. In diesem Fall sollte das Tagebuch lediglich den Eintrag keine Einträge enthalten. (Eine Abgabe ist deswegen gefordert, um unterscheiden zu können zwischen (a) die Abgabe wurde vergessen und (b) ein leeres Projekttagebuch wurde abgegeben.) 5

7 Section 4 Projekttagebuch ein Teammitglied hält sich (wiederholt) nicht an Absprachen bzw. Zusagen Das Projekttagebuch dokumentiert ausschließlich projektgefährdende Ereignisse. Im Regelfall enthält das Projekttagebuch deshalb auch keine Einträge. Beispiele für projektgefährdende Ereignisse sind: ernsthafte Erkrankungen der Teammitglieder/des Teamleiters/ des Auftraggebers der Auftraggeber hat Zusagen (zum Beispiel in Hinblick auf das zur Verfügung stellen von Hardware/Software oder Spezifikationen) nicht eingehalten der Auftraggeber (d.h. der Ansprechpartner) wechselt die Aufgabenstellung wird während der Projektphase grundlegend geändert (In diesem Fall nehmen Sie bitte auch umgehend mit der Projektbegleitung Kontakt auf.) ein Teammitglied verlässt die Gruppe 6

8 Section 5 Qualitätssicherungsdokument Überblick Das Ziel des Qualitätssicherungsdokuments ist es zu beschreiben, wie die Qualität des zu erstellenden Produktes im Rahmen des gewählten Projektes gesichert wird. Dies umfasst sowohl die (I) Beschreibung des Prozesses der Qualitätssicherung als auch (II) der Ziele und (III) der gewählten Maßnahmen. Darüber hinaus muss das Dokument den Qualitätssicherungsprozess beschreiben. D.h. wann wird welche Maßnahme durch wen durchgeführt und wie wird auf gefundene Qualitätsprobleme reagiert. Ist eine Erreichung der durch den Auftraggeber (explizit oder implizit) vorgegebenen Qualitätsziele im Rahmen des Projekts nicht (mehr) möglich, so ist zu begründen warum dies nicht mehr möglich ist und warum davon am Anfang davon ausgegangen wurde, dass die Ziele erreichbar und die Maßnahmen durchführbar sind. Weiterhin ist darzulegen, welche alternativen Qualitätsziele verfolgt wurden und welche Maßnahmen mit welchem Prozess durchgeführt wurden. Der mit Projektende abzugebende Anhang belegt, dass die Qualitätssicherung wie beschrieben durchgeführt wurde. Dabei ist ausgehend von den für das Projekt relevanten und im Idealfall mit dem Auftraggeber abgestimmten Qualitätszielen zu beschreiben, wie die entsprechenden Qualitätssicherungsmaßnahmen aussehen. Es ist darauf zu achten, dass alle im Dokument beschriebenen Prozesse, Ziele und Maßnahmen im Kontext des konkreten Projektes erreichbar und durchführbar sind. Eine mögliche Maßnahme, um zum Beispiel hohe Codequalität zu erreichen, ist die regelmäßige, strukturierte Durchführung von Code Reviews oder der regelmäßige Einsatz von Tools zur statischen/dynamischen Analyse. 7

9 Eine mögliche Vorlage (I) Beschreibung des projektspezifischen Qualitätszieles & kurze Begründung: Im Rahmen dieses Projektes hat die Sicherstellung der höchste Priorität, da. (II) Beschreibung der Maßnahmen, die durchgeführt werden, um das Erreichen des Zieles sicherzustellen: Um das Qualitätsziel zu erreichen, führen wir regelmäßig Tests/Studien/Code Reviews/Schulungen/ durch. [Aussagen, die die Maßnahme genau beschreiben.] Weiterhin setzen wir folgende Werkzeuge ein, die. (III) Beschreibung des Prozesses: Die Maßnahme wird alle durchgeführt. Die Ergebnisse werden... diskutiert und einem Entwickler zum Lösen zugewiesen. Für geänderten Code wird der selbe Qualitätssicherungsprozess angewandt wie für neuen. 8

10 Allgemeine Hinweise Es handelt sich um ein Dokument im TU Darmstadt Design mit max. 10 Seiten (ohne Anhang); die von der Projektbegleitung zur Verfügung gestellte Vorlage ist zu verwenden. Auf dem Deckblatt sind zu vermerken: Das Projektthema/der Titel des Projekts Die vollständigen Namen der Teammitglieder Kontakt ( ) nen Umständen eine Einführung (in welcher Hinsicht auch immer) in Qualitätssicherung enthält. Sollte der Auftraggeber dies explizit wünschen, so ist dies auch explizit auf dem Dokument zu vermerken. Vergessen Sie nicht die Qualität des Qualitätssicherungsdokumentes zu sichern! Stellen Sie insbesondere sicher, dass die folgenden Fragen in Ihrem Dokument beantwortet sind: Ergibt sich aus der Projektbeschreibung, warum die dargestellten Ziele, die essentiellen Ziele sind? Welches sind die zentralen Qualitätsziele des Projekts? Der vollständige Name des Teamleiters Warum sind dies die zentralen Ziele? Name der Auftraggeber(in)/des Auftraggebers (inkl. Fachgebiet/Fachbereich) Welche Maßnahmen werden durchgeführt? Gruppennummer Ein Qualitätssicherungsziel, dass von Seiten der Projektbegleitung gesetzt ist und dass alle Gruppen im Rahmen des Qualitätssicherungsdokumentes beschreiben müssen ist die Sicherung der Qualität des Codes im weiteren Sinn. Hierbei ist zu beachten, dass auch dieses Ziel auf das konkrete Projekt angepasst werden muss. Wie dienen die Maßnahmen dem Erreichen der gegebenen Ziele? Sind die Maßnahmen dafür geeignet die Ziele zu erreichen? Durch wen werden die Maßnahmen durchgeführt und wie wird auf Probleme bis wann reagiert? Ist die Häufigkeit, mit der die Maßnahmen durchgeführt wird angemessen? Bitte beachten Sie, dass sofern der Auftraggeber nichts anderes wünscht das Qualitätssicherungsdokument unter kei9

11 Qualitätsmerkmale Sicherheit (eng. Safety) Genauigkeit Angemessenheit Funktionalität Eigenschaft eines Systems weder Menschen, noch Sachen oder die Umwelt zu gefährden. Interoperabilität Sicherheit Reife Fehlertoleranz Zuverlässigkeit Wiederherstellbarkeit Verständlichkeit Datensicherheit (eng. Security) Eigenschaft eines Systems Informationsverluste und unbefugten Datenzugriff zu verhindern. Erlenbarkeit Software Qualitätsmerkmale Benutzbarkeit Bedienbarkeit Attraktivität (angelehnt an ISO 9126) Effizienz Zeitverhalten Verbrauchsverhalten Analysierbarkeit Wartbarkeit Änderbarkeit Stabilität Zuverlässigkeit Die Wahrscheinlichkeit des ausfallfreien Betriebs der (in diesem Kontext) Software über einen bestimmten Zeitraum bei einer definierten Betriebsweise. Testbarkeit Anpassbarkeit Portabilität Installierbarkeit Koexistenz Austauschbarkeit Korrektheit Grad der Konsistenz zwischen Spezifikation und Programm bzw. als Grad der Erfüllung der Benutzererwartung durch ein Programm (d.h. ohne Spezifikation ist keine Korrektheit nachweisbar). Verfügbarkeit Eigenschaft zu einem gegebenen Zeitpunkt funktionstüchtig zu sein. Robustheit Im Wesentlichen eine Eigenschaft der Spezifikation. Resultiert im Wesentlichen aus der korrekten Umsetzung einer Spezifikation, die auch ungewöhnliche Betriebssituationen erfasst. Vollständigkeit Alle geforderten Funktionen sind realisiert. 10

12 Beschreibung eines Qualitätszieles Beispiel Projektspezifische Motivation des Projektzieles Scope / Umfang/ Ziel Qualitätsziel: Vermeidung von Datenverlusten Im Rahmen des Projektes wird eine Webanwendung entwickelt, auf die über das Internet zugegriffen wird. Da diese Anwendung personenbezogene Daten verarbeitet und potentiellen Angriffen ausgesetzt ist, ist ein wesentliches Qualitätsziel, dass die Anwendung keine Sicherheitslücken aufweist über die Angreifer Daten anderer Benutzer abgreifen können. Im Rahmen dieses Projektes können wir jedoch nur gewährleisten, dass die Webanwendung keine Standardlücken wie zum Beispiel SQL Injection aufweist. Um dieses Ziel zu erreichen, setzen wir die folgenden Tools: ein. Darüber hinaus wurde ein Entwickler benannt, der sich maßgeblich um das Thema Sicherheit in Webanwendungen kümmert und Die automatisierte Analyse des Codes der Webanwendung erfolgt im Rahmen des regelmäßigen Nightly Builds. Sollte ein Problem gefunden werden, so geht eine Mail an alle Entwickler und im Rahmen des nächsten (gruppeninternen) Meetings wird dann ein Entwickler bestimmt, der den Fehler beseitigt. Wann und durch wen? Wie wird darauf reagiert? 11

13 Typische Probleme (Alle im Folgenden wiedergegeben Ausschnitte entstammen (Vorabgaben von) Qualitätssicherungsdokumenten der vergangen Jahre.) Durch eine Evaluation kann man die Benutzerfreundlichkeit ermitteln, aber nicht gewährleisten! Bindestriche werden wahllos platziert. Aussagen aus QS Dokumenten Qualitäts-Faktoren Umgangssprachlich Hier beißt sich also die Katze in gewissem Sinne in den eigenen Schwanz. Die Rechtschreibung insbesondere in Hinblick auf die Anwendung der Kommaregeln ist sehr schlecht. Tipp: Komm wir essen Opa (Satzzeichen retten leben) Die Struktur des Dokumentes hält sich nicht an die etablierten Regeln. Insbesondere gibt es Kapitel mit nur einem Unterkapitel statt mindestens zwei Unterkapiteln. Tipp: Nehmen Sie sich ein (ggf. elektonisches) Buch eines renommierten Verlages und strukturieren Sie das Dokument in vergleichbarer Weise. Eats(,) Shoots & Leaves Deutsch und Englisch werden wild gemischt. Einzelne Sätze machen schon für sich alleine genommen keinen Sinn. Außerdem soll eine Evaluation die Benutzerfreundlichkeit der Anwendung gewährleisten. Im Weiteren werden folgende Qualitätsfaktoren [...]: Correctness 12

14 Robustness Extendibility Es wird nicht präzise beschrieben, was getan wird. Statt dessen wird beschrieben, was möglicherweise getan werden könnte. Um dies zu beschleunigen, wollen wir eine Dokumentation über die Schnittstellen unserer Software bereitstellen. Der Qualitätssicherungsprozess ist nicht zu Ende gedacht bzw. nicht ausreichend beschrieben. Am Ende des Projektes führen eine Benutzerstudie durch, um [...] zu erreichen. Dinge, die am Ende des Projektes gemacht werden, können faktisch keine wesentliche Auswirkung mehr auf das Produkt haben und somit der Erreichung eines Qualitätszieles nicht mehr dienen. Tipp: Geben Sie immer (relativ) präzise an, wann Sie eine Maßnahme durchführen werden und überlegen Sie sich genau, ob der Zeitraum, der nach der Durchführung der Maßnahme noch zur Verfügung steht, ausreicht, um ggf. das Ziel noch (teilweise) zu erreichen. Es werden bei weiten zu viele Qualitätsziele und Maßnahmen beschrieben und verfolgt. Tipp: Fragen Sie sich genau was im Rahmen dieses Projektes am Wichtigsten ist, wie viel Sie zeitlich leisten können und an welchen Stellen die größten Risiken liegen bzgl. der Nichterreichung des Projektzieles. Der Abstraktionsgrad innerhalb eines Abschnitts springt wild hin und her. Es werden Qualitätsziele, die für das Projekt nicht relevant sind, und Maßnahmen, die nicht durchgeführt werden, beschrieben. Zu beschreiben, was nicht getan wird, macht fast ausschließlich nur dann Sinn, wenn Sie den Umfang einer Maßnahme begrenzen wollen auf ein für das Projekt sinnvolles Maß. Jedes eingesetzte Werkzeug wird als Qualitätssicherungswerkzeug betrachtet. Als integrierte Entwicklungsumgebung (IDE) wird Netbeans verwendet, wodurch Syntaxfehler vermieden werden. 13

15 QS-Werkzeuge[ ] Skype [Sky] ist eine kostenlose Voice Over IP (VOIP) Software, welche zusätzlich noch die Funktionen zu Instant Messaging, Dateiübertragung und Videotelefonie bietet. Im Rahmen des Projektes wurde ein Chatraum in Skype eingerichtet, in welchem sich täglich über das Projekt ausgetauscht wurde. Skype unterstützte die Teamarbeit. jektbegleitung sein. Schreiben Sie also nichts, was Personen, die sich seit vielen Jahren mit Fragen der Softwaretechnik beschäftigen, auf jeden Fall wissen. Sollte der Auftraggeber Interesse an dem Qualitätssicherungsdokument zeigen und dieses (weiter)verwenden wollen, dann benennen Sie die Zielgruppen bitte am Anfang des Dokumentes. Integrierte Entwicklungsumgebungen, Versionskontrollsysteme, Projektmanagementsoftware und Chatclients dienen primär/ ausschließlich der Produktivität bzw. der Steuerung des Projektes jedoch nicht der eigentlichen Produktqualität. Inversion des Kontrollflusses: Durch den Einsatz des Frameworks wird erreicht, dass sich der Entwickler nicht mehr um den Kontrollfluss der Web-Anwendung kümmern muss. Das erledigt das Framework für ihn. Der Projektbezug ist nicht gegeben und es handelt sich um eine allgemeingültige Feststellung. Blah, Blah, Blah Unser Auftraggeber ist zufrieden, wenn unser Produkt am Ende eines Sprints die Akzeptanzkriterien der mit ihm im Gespräch entwickelten User Stories erfüllt. Wenn unser Auftraggeber zufrieden ist, sind wir zufrieden. [...] Tipp: Bedenken Sie immer die Zielgruppe, für die Sie ein Dokument erstellen. In diesem Fall dürfte es fast immer (nur) die Pro- Statt einem Qualitätsziel wird eine (nicht-)funktionale Anforderung beschrieben. Schwammige Aussagen Um möglichst fehlerfreien Code zu erreichen, werden wir umfangreiche Tests zusätzlich zum Code entwickeln. 14

16 Hier stellt sich unter anderem die Frage nach dem Umfang von umfangreichen Tests? Ähnliche Aussagen finden sich häufig auch in Hinblick auf die Dokumentation des Codes. Tipp: Es ist häufig hilfreicher/einfacher den Umfang einer Testsuite über die (Kern-)Komponenten bzw. über die umzusetzenden Features zu beschreiben. 15

17 Der Anhang des Qualitätssicherungsdokumentes quenzen gezogen wurden (z.b. durch Referenz auf zeitlich nachfolgende User Stories). Der Anhang muss dokumentieren, dass die beschriebenen Qualitätsmaßnahmen und Prozesse auch durchgeführt wurden. Es ist hierbei insbesondere darauf zu achten, dass erkenntlich ist, dass der Prozess eingehalten wurde (d.h. wann und wie häufig etwas getan wurde) und auch, dass die Maßnahmen im beschriebenen Umfang durchgeführt wurden. Dokumentation des Quellcodes Im Folgenden stellen wir für typische Maßnahmen bzw. Ziele dar, wie diese ggf. zu belegen sind. Lesen Sie auf jeden Fall alle Abschnitte, da viele Dinge ggf. auf Ihre Maßnahmen und Ziele übertragbar sind. Benutzerstudie Im Anhang muss dokumentiert sein, wann diese Studie(n) von wem und mit welchen Probanden durchgeführt wurde. Darüber hinaus sind die ausgefüllten Fragebögen und auch die entsprechenden aggregierten Ergebnisse anzuhängen. Wurden die Probanden beobachtet, dann sind die entsprechenden Protokolle anzuhängen. Insbesondere ist kurz zu dokumentieren, welche Ergebnisse aus der Benutzerstudie abgeleitet wurden und welche Konse- Ist eine Maßnahme, die versprochen wurde, dass der Code dokumentiert wurde, so ist hier ein Auszug des Codes abzugeben. Der Auszug muss aus mindestens drei verschiedenen Klassen, Headerfiles oder etwas vergleichbaren Bestehen. Die Dateien müssen von der Anzahl der Zeilen Code her repräsentativ für das Projekt sein. Die gewählten Dateien müssen weiterhin von herausgehobener Bedeutung für das Projekt sein und dies muss entweder aus der Dokumentation hervorgehen oder gesondert kurz dargelegt werden. Der Code ist direkt in den Anhang zu integrieren. Automatisierte Tests Sollte das QS Dokument angeben, dass die Software automatisiert getestet wurde, so ist die vollständige Liste der Tests abzugeben und es ist zu belegen welche Teile des Codes getestet wurden. Dies kann insbesondere dadurch geschehen, dass ein Auszug eines Codeabdeckungstools angehängt wird; dargestellt auf Klassen-/Dateiebene. Bitte geben Sie auf jeden Fall für die Tests auch an auf welche Anforderungen/User Stories/Funktionalität sich die Tests beziehen. Geht aus dem Namen des Tests hervor, worauf sich selbiger bezieht, so ist dies ausreichend. 16

18 Modularität bzw. Erweiterbarkeit Manuelle Tests Um zu belegen, dass das Ziel erreicht wurde sind die zentralen Schnittstellen inkl. der unmittelbaren Abhängigkeiten zu dokumentieren. In diesem Fall ist der Testplan anzugeben falls er nicht bereits im Hauptteil angegeben wurde. Aus dem Testplan muss hervorgehen, dass das beschriebene Qualitätsziel in vollem Umfang sichergestellt werden kann. Ein Testplan muss immer mind. folgende Informationen beinhalten: die durchzuführenden Schritte und die jeweiligen erwarteten Ergebnisse. Darüber hinaus sind die Abhängigkeiten zwischen den Klassen/ Modulen/Packages/Maven Artefakten/... genau zu dokumentieren. Abzugeben ist die Dokumentation des Standes der Erweiterbarkeit/Modularisierung am Ende des Projektes zuzüglich einer kurzen Übersicht, wann die Maßnahmen Analyse der Struktur, Definition und Besprechung der Schnittstellen, etc. durchgeführt wurden. Darüber hinaus sind die Protokolle abzugeben, welche die Ergebnisse der jeweiligen Durchführung und die ggf. gezogenen Konsequenzen angeben. Es ist auch anzugeben, wann die Tests von wem durchgeführt wurden. Code Reviews Diesbezüglich ist eine Checkliste anzuhängen falls diese nicht bereits im Hauptteil dargestellt ist aus der genau hervorgeht, was alles geprüft wird und wann die Prüfung als erfolgreich gilt. Es sind auch alle ausgefüllten Checklisten anzuhängen. Aus diesen muss jeweils hervorgehen, wann die Prüfung durch wen erfolgt ist und welche Teile einem Review unterzogen wurden. Etwaige gezogene Konsequenzen sind zu dokumentieren (analog zu Benutzerstudie ). 17

19 Ausgewählte Qualitätsmerkmale bzw. -maßnahmen. (Gut/Umfangreich/...) dokumentierter Code Documentation costs much time, usually more than actual implementation. That s the reason why people try to avoid documentation. (From: How Do Professional Developers Comprehend Software?; Tobias Boehm, Rebecca Tiarks, Rainer Koschke, Walid Maalej; ICSE 2012; IEEE) Falls Sie manuelle (GUI-)Tests durchführen, dann ist der Testplan einzureichen. Falls Sie automatisierte Tests durchführen, dann ist die vollständige Liste aller (Unit)Tests abzugeben. In allen Fällen muss erkenntlich sein, wann die Test durch wen und mit welchem Ergebnis durchgeführt wurden. Sollten Tests fehlgeschlagen haben, dann ist zu dokumentieren wann diese behoben wurden. Sollten Sie dieses Qualitätsziel gewählte haben, dann belegen Sie die gute/ausreichende Dokumentation Ihrer Software dadurch, dass Sie uns die generierte Dokumentation (HTML Seiten, PDF,...) zur Verfügung stellen. Im QS Dokument ist dann ggf. auf das/die PDFs bzw. die Hauptseite zu verweisen. (Gut/...) getesteter Code Um zu belegen, dass Sie Ihren Code getestet haben stellen Sie uns folgende Informationen zur Verfügung: Eine Analyse der Codeabdeckung (unabhängig davon ob Sie automatisierte oder manuelle Tests durchgeführt haben); spezifizieren Sie genau das zugrunde gelegte Codeabdeckungsmaß und das verwendete Werkzeug. Zum Beispiel mit ECL Emma (bei Javaprogrammen). 18

20 Werkzeuge Sprachunabhängig Im Folgenden sind einige wenige Werkzeuge aufgeführt, die im Rahmen einer systematischen Qualitätssicherung eingesetzt werden können. Gerrit (Code Review System) Java Selenium (Primarily, for testing web applications) Apache JMeter (Last- und Performancetests) Hammurapi (Verletzungen von Best Practices ) PMD (Verletzungen von Konventionen und Best Practices ) Checkstyle (Verletzungen von Konventionen) Findbugs (Verletzungen von Best Practices ) JLint (Verletzungen von Best Practices - mit Fokus auf nebenläufige Programme) (im Allgemeinen: x Lint.) ECLEmma (Abdeckung des Codes durch eine Testsuite) Java Path Finder (Software Model Checking and much more...) JDepend (Abhängigkeitsanalysen) Dependency Finder (Abhängigkeitsanalysen) Stan (Strukturanalysen) Cloc (Metriken) 19

21 Section 6 Benotung Die Bewertung der Gruppe ist vollständig unabhängig von der Benotung des Teamleiters und der Teamleiter wird auch nicht in die Notengebung der Gruppe eingebunden. Weiterhin geht der Vortrag, der im Rahmen der Vorlesung zu halten ist, in die Endnote ein. Die Endnote für die Bachelor-Praktikumsgruppe ergibt sich aus der Bewertung durch den Auftraggeber und aus der Bewertung durch die Projektorganisation. Beide Noten gehen zu 50% in die Endnote ein. Die Benotung der Projektorganisation stützt sich insbesondere auf die erstellten und abgegebenen Dokumente (basierend auf den Besonderheiten der Projekte). Sollte der agile Softwareentwicklungsprozess gewählt worden sein, dann ist dies insbesondere das Qualitätssicherungsdokument inkl. Anhang, der belegt, dass die Qualitätssicherung wie beschrieben durchgeführt wurde. Darüber hinaus wird die vollständige Dokumentation der Anforderungen herangezogen. Das Projekttagebuch dient - insbesondere für den Fall, dass es im Rahmen der Bearbeitung des Projektes zu Problemen, Verzögerungen oder Streitigkeiten (zwischen den Gruppenmitgliedern/mit dem Auftraggeber) gekommen ist - dazu, zu ermitteln woher die Schwierigkeiten kamen und ob diese (auch) in der Verantwortung der Studierenden lagen. Es dient ggf. als Basis für eine faire Benotung. In der Regel wird die Gruppe als Ganzes bewertet. Einzelnoten werden nur im Sonderfall und aufgrund des expliziten Wunsches der Gruppe bzw. bei besonderen Problemen vergeben. Im Falle des Unified Process wird insbesondere das Pflichtenheft bewertet. 20

22 Section 7 Agiler Softwareentwicklungsprozess Im Folgenden wird kurz beschrieben, wie sich ein von Extreme Programming und Scrum inspiriertes agiles Softwareprozessmodell im Rahmen des Bachelor-Praktikums umsetzen lässt. Insbesondere geht dieses Dokument darauf ein, an welchen Stellen Kompromisse eingegangen werden müssen, die sich aus der Besonderheit ergeben, dass es sich um eine Lehrveranstaltung handelt. anzuwenden, die die Software flexibel und anpassbar bzw. wartbar machen. Dazu muss man sich entsprechender Entwurfsmuster bewusst sein. Darüber hinaus ist es erforderlich Vorgehensweisen anzuwenden, die die nötige Disziplin sicherstellen und den Fortschritt zu ermitteln. Das wesentliche Ziel ist es, den Auftraggeber zu ermöglichen das Entwicklungsteam in die Richtung zu steuern, welche den höchsten Geschäftswert verspricht. Dazu ist es erforderlich, dass man auf Änderungen flexibel reagiert. Wesentliche Eckpunkte: Die regelmäßige und häufige Zusammenarbeit mit dem Kunden Der große Vorteil eines agilen Softwareentwicklungsprozesses ist, dass der Auftraggeber in einem kontrollierten Rahmen stets die Möglichkeit hat, das Projekt in die Richtung zu steuern, welche den höchsten Nutzen verspricht. Die häufige Auslieferung laufender Software, die einen Geschäftsnutzen hat; Fortschritt wird gemessen durch die Funktionalität, die umgesetzt wurde Grundlagen und Motivation Agiler Softwareentwicklungsprozesse Das Team reflektiert über die Entwicklungsprozesse Sich selbst organisierende Teams mit motivierten Individuen Streben nach technischer Exzellenz und einem guten Entwurf Das Ziel ist es Software zügig und zielstrebig zu entwickeln in der Gegenwart sich ständig ändernder Anforderungen. Um dieses Ziel zu erreichen ist es notwendig Entwurfsprinzipien 21

23 Geeignete Projekte Agile Softwareentwicklung eignet sich für Projekte, bei denen die Anforderungen bzw. die Prioritäten der einzelnen Anforderungen an die zu erstellende Software bei Beginn des Projekts nicht vollständig bekannt sind bzw. bei denen es Wahrscheinlich ist, dass sich die Anforderungen noch ändern werden. Informatikkenntnisse sind auf Seite des Auftraggebers nicht erforderlich - der Auftraggeber bzw. Kunde handelt aus seiner fachlichen Perspektive heraus. Dies sind häufig Projekte, bei denen es um die Erstellung von Webanwendungen oder anderweitigen Geschäftsanwendungen geht. Voraussetzungen auf Seiten des Projektteams Das Team sollte sich mit den Grundlagen agiler Softwareentwicklungsprozesse auseinandergesetzt haben. Darüber hinaus ist eine stetige Leistungsbereitschaft erforderlich, damit der Auftraggeber seiner Steuerungsfunktion nachkommen kann. Voraussetzungen auf Seiten des Auftraggebers Dieses Vorgehensmodell setzt voraus, dass sich der Auftraggeber zu regelmäßigen Treffen alle 2 bis 3 Wochen bereit erklärt. D.h. die Wahl dieses Prozessmodells setzt das Einverständnis des Auftraggebers voraus. 22

24 Ablauf während des Praktikums Start Im Folgenden wird davon ausgegangen, dass die einzusetzenden Technologien (Programmiersprachen etc.) bereits gesetzt sind falls dies nicht der Fall ist, dann kann bei Bedarf erst noch eine Explorationsphase vorangestellt werden. Gleiches gilt, falls das Team nicht über notwendige fachliche Kenntnisse verfügt, oder die Vorstellungen des Auftraggebers am Anfang noch sehr vage sind. In diesem Fall bietet es sich an weitere Techniken zur Anforderungsermittlung (z.b. Anwendungsfälle (Use Cases), offene Interviews oder Szenariotechniken) einzusetzen, um ein breites Verständnis für die zu entwickelnde Anwendung zu bekommen. Im Rahmen der regelmäßigen Treffen mit den Auftraggebern sind die Anforderungen an die zu entwickelnde Software in Form von (neuen) User Stories zu erfassen bzw. gegebene ggf. zu verfeinern. Im Rahmen des ersten Treffens sollte versucht werden auf einem hohen Abstraktionsniveau alle wesentlichen User Stories zu erfassen. Die User Stories, die im Rahmen der ersten Iteration umgesetzt werden sollen, müssen natürlich im Rahmen der ersten Iteration auch bereits passend herunter gebrochen werden. Aufbauend auf den erfassten User Stories wird eine Releaseplanung für das gesamte Projekt durchgeführt (zwei bis drei Relea- ses). Ein Release ist dadurch gekennzeichnet, dass es einen aus fachlicher Sicht sinnvollen Funktionsumfang umfasst. Diese soll dann im Rahmen des zweiten Treffens mit dem Auftraggeber vorgestellt werden. Während des Projekts Am Ende/am Beginn jeder Iteration treffen sich der Auftraggeber und das Team und besprechen die Ergebnisse der letzten Iteration. In diesem Rahmen stellt das Team die umgesetzten User Stories vor und der Auftraggeber nimmt diese ggf. ab. Auf Wunsch des Auftraggebers muss das Team in der Lage sein, am Ende jeder Iteration eine lauffähige Version zur Verfügung zu stellen, damit der Auftraggeber diese testen kann, um ggf. die weitere Entwicklungsrichtung zu bestimmen. Sollten neue Anforderungen aufkommen, so sind diese unmittelbar als neue User Stories zu erfassen. Weiterhin wird besprochen welche User Stories im Rahmen der nächsten Iteration umzusetzen sind (Planning Meeting). Es ist darauf zu achten, dass nur so viele User Stories durch den Auftraggeber gezogen werden, wie auch umgesetzt werden können. Falls die Geschwindigkeit des Teams noch nicht bekannt ist bzw. stark schwankt, dann ist es sinnvoll, dass der Auftraggeber den User Stories Prioritäten zuordnet, damit das Team eine genaue Vorstellung davon hat, in welcher Reihenfolge die User Stories umzusetzen sind. Insbesondere werden große User Stories herunter gebrochen, um diese durchführbar zu machen. 23

17.04.12. Agile Softwareentwicklung. im Rahmen des Bachelor-Praktikums des. Fachbereichs Informatik

17.04.12. Agile Softwareentwicklung. im Rahmen des Bachelor-Praktikums des. Fachbereichs Informatik Agile Softwareentwicklung im Rahmen des Bachelor-Praktikums des Fachbereichs Informatik 17.04.12 In diesem Dokument wird kurz beschrieben, wie sich ein von Extreme Programming und Scrum inspiriertes agiles

Mehr

First Edition. BachelorPraktikum. Hinweise für Teilnehmer. Dr. Michael Eichberg Johannes Lerch Joscha Drechsler

First Edition. BachelorPraktikum. Hinweise für Teilnehmer. Dr. Michael Eichberg Johannes Lerch Joscha Drechsler First Edition BachelorPraktikum Hinweise für Teilnehmer Dr. Michael Eichberg Johannes Lerch Joscha Drechsler Bachelor-Praktikum 1 Die wesentlichen Elemente des Bachelor-Praktikums am Fachbereich Informatik

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

Qualität 1. 1 Qualität

Qualität 1. 1 Qualität Qualität 1 1 Qualität Nach dem Durcharbeiten dieses Kapitels sollten Sie die Qualität für ein Softwaresystem definieren können, typische Qualitätskriterien kennen, Qualitätskriterien messbar festlegen

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing.

SOFTWARETECHNIK. Kapitel 7 Vorgehensmodelle. Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. SOFTWARETECHNIK Kapitel 7 Vorgehensmodelle Vorlesung im Wintersemester 2012/13 FG System- und Software-Engineering Prof. Dr.-Ing. Armin Zimmermann Inhalt Vorgehensmodelle Sequenzielle Modelle Iterative

Mehr

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Projektplan Software Engineering Projekt November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Der Projektplan Grundlage der gemeinsamen Arbeit innerhalb des Teams und mit

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation

Softwareentwicklungspraktikum Sommersemester 2007. Testdokumentation Softwareentwicklungspraktikum Sommersemester 2007 Testdokumentation Auftraggeber Technische Universität Braunschweig

Mehr

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de SCRUM Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter Dirk.Prueter@gmx.de Überblick Was ist SCRUM Wie funktioniert SCRUM Warum lohnt es sich, SCRUM anzuwenden

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten Projektmanagement Agile Methoden: Extreme Programming / Scrum Dokument V 1.2 Probleme bei Projekten Viel Arbeit, die an den Zielen vorbeigeht Viel Dokumentation für f r unbenutzte Bestandteile Fehlende

Mehr

Einführung in SCRUM. Helge Baier 21.01.2010

Einführung in SCRUM. Helge Baier 21.01.2010 Einführung in SCRUM Helge Baier 21.01.2010 Helge Baier Master of Computer Science (Software Engineering) über 10 Jahre Erfahrung in der Software Entwicklung Zertifizierung zum Scrum Master (2009) praktische

Mehr

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming /

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming / Software- Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.2-2010 Projektmodelle im Vergleich Klassisch Wasserfall -Modell Spezifikation/Pflichtenheft

Mehr

Softwarequalität: Einführung. 15. April 2015

Softwarequalität: Einführung. 15. April 2015 Softwarequalität: Einführung 15. April 2015 Überblick Warum ist Softwarequalität wichtig? Was ist Softwarequalität? Wie erreicht man Softwarequalität? Taentzer Softwarequalität 2015 8 Berühmte Software-Fehler

Mehr

- Agile Programmierung -

- Agile Programmierung - Fachhochschule Dortmund Fachbereich Informatik SS 2004 Seminar: Komponentenbasierte Softwareentwicklung und Hypermedia Thema: - - Vortrag von Michael Pols Betreut durch: Prof. Dr. Frank Thiesing Übersicht

Mehr

Werte und Prinzipien der agilen Softwareentwicklung

Werte und Prinzipien der agilen Softwareentwicklung 1 Was ist Scrum? Scrum ist ein einfaches Projektmanagement-Framework, in das Entwicklungsteams selbstbestimmt erprobte Praktiken einbetten. Der Rahmen sieht einen empirisch, iterativen Prozess vor, bei

Mehr

RE-Metriken in SCRUM. Michael Mainik

RE-Metriken in SCRUM. Michael Mainik RE-Metriken in SCRUM Michael Mainik Inhalt Agile Methoden Was ist SCRUM? Eine kurze Wiederholung Metriken Burn Down Graph Richtig schätzen Running Tested Features WBS/ Earned Business Value Business Value

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Projektmanagement. Projektmanagement

Projektmanagement. Projektmanagement Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen Scrum technische Umsetzung und kaufmännische 9. Darmstädter Informationsrechtstag 2013 Darmstadt, 15. November 2013 Franziska Bierer 2 andrena ojects ag Gründung 1995 Standorte in Karlsruhe und Frankfurt

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch Agiles Testmanagment Hugo Beerli bbv Software Services AG Luzern, September 2011 Product Backlog (Agenda) 1) Warum System Tests 2) Agile Arbeitsmethode Stand up Meeting 3) Vorteile der agilen Methode 4)

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Agile Methoden bei der Entwicklung medizinischer Software

Agile Methoden bei der Entwicklung medizinischer Software Agile Methoden bei der Entwicklung medizinischer Software Bernhard Fischer Fischer Consulting GmbH Fischer Consulting GmbH Technologie-Forum 2008 Folie 1 Wie soll Software entwickelt werden? Fischer Consulting

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Testen in KMU Projekten Bern, November 2013

Testen in KMU Projekten Bern, November 2013 Testen in KMU Projekten Bern, November 2013 Beraterprofil Stephan Wiesner Beratungsschwerpunkte Beratungsschwerpunkte Testmanagement Testautomation Entwicklung und Testen im Mobile-Umfeld Applikationsschwerpunkte

Mehr

Requirements Engineering für die agile Softwareentwicklung

Requirements Engineering für die agile Softwareentwicklung Johannes Bergsmann Requirements Engineering für die agile Softwareentwicklung Methoden, Techniken und Strategien Unter Mitwirkung von Markus Unterauer dpunkt.verlag Inhaltsverzeichnis 1 Einleitung 1 1.1

Mehr

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014

Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering 4. Methodologien Franz-Josef Elmer, Universität Basel, HS 2014 Software Engineering: 4. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten

Mehr

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler

Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Gruppe 2: Rui Gu, Wei Zhu, Veysel Imamoglu, Dimitar Dimitrov, Karl Oppermann, Nathalie Hrycej, Markus Schnalke, Christoph Galler Modellgetriebene Softwareentwicklung auf Basis von TOPCASED am Beispiel

Mehr

Praxisbericht und Demo-Projektabwicklung mit der ATLASSIAN Toolchain und Continuous Integration. Markus Stollenwerk, Noser Engineering AG

Praxisbericht und Demo-Projektabwicklung mit der ATLASSIAN Toolchain und Continuous Integration. Markus Stollenwerk, Noser Engineering AG Praxisbericht und Demo-Projektabwicklung mit der ATLASSIAN Toolchain und Continuous Integration Markus Stollenwerk, Noser Engineering AG Agile Softwareentwicklung Crash-Kurs Markus Stollenwerk, 27.9.2013

Mehr

Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG

Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG Was fehlt Scrum? 31. März 2014 Erich Oswald CTO Ergon Informatik AG Scrum ist eine Erfolgsstory Aus der Praxis entstanden Nachweislich erfolgreich Gut geeignet für komplexe Probleme Produktentwicklung

Mehr

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-42660-3. Weitere Informationen oder Bestellungen unter

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-42660-3. Weitere Informationen oder Bestellungen unter Ralf Wirdemann Scrum mit User Stories ISBN: 978-3-446-42660-3 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42660-3 sowie im Buchhandel. Carl Hanser Verlag, München 1 Einführung.....................................

Mehr

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept Testkonzept 1.Einführung Um die Zuverläsigkeit und die Qualität der Software und des gesamten Systems zu verbessern, sind Tests durchzuführen. Die Testreihe läst sich in drei Stufen einteilen, nülich Komponententest,

Mehr

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

Mehr

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen Bernhard Fischer Fischer Consulting GmbH MedConf 2009 Folie 1 Wie soll Software entwickelt werden? MedConf 2009 Folie

Mehr

Projektmanagement-Plan

Projektmanagement-Plan Applikationsentwicklung FS14 Gruppe 20 Horw, 29.05.2014 Bontekoe Christian Estermann Michael Rohrer Felix Autoren Bontekoe Christian Studiengang Informatik - Software Systems (Berufsbegleitend) Adresse

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Softwarequalität: Definitionen, Wünsche, Grenzen

Softwarequalität: Definitionen, Wünsche, Grenzen Softwarequalität: Definitionen, Wünsche, Grenzen iks Thementag Mehr Softwarequalität Ausgewählte Themen 22.05.2014 Autor: Christoph Schmidt-Casdorff Agenda Einführung Was ist Softwarequalität? Qualität

Mehr

IV::SOLUTIONFRAMEWORK

IV::SOLUTIONFRAMEWORK IV::SOLUTIONFRAMEWORK EINFÜHRUNG Das IV::SolutionFramework ist die Antwort der INTERVISTA AG auf die Anforderungen an moderne IT Entwicklungsprojekte. Effiziente Vorgehensmodelle und die Einführung von

Mehr

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-41656-7. Weitere Informationen oder Bestellungen unter

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: 978-3-446-41656-7. Weitere Informationen oder Bestellungen unter Ralf Wirdemann Scrum mit User Stories ISBN: 978-3-446-41656-7 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41656-7 sowie im Buchhandel. Carl Hanser Verlag, München 1 Einführung.....................................

Mehr

AGILES QUALITÄTSMANAGEMENT

AGILES QUALITÄTSMANAGEMENT AGILES QUALITÄTSMANAGEMENT Manfred Rätzmann Head of Department Quality Assurance Deutsche Post E-Post Development GmbH Manfred.Raetzmann@epost-dev.de http://www.epost.de/ Klassische Ziele des Qualitätsmanagements:

Mehr

Agile Entwicklung nach Scrum

Agile Entwicklung nach Scrum comsolit AG Hauptstrasse 78 CH-8280 Kreuzlingen Tel. +41 71 222 17 06 Fax +41 71 222 17 80 info@comsolit.com www.comsolit.com Agile Entwicklung nach Scrum Seite 1 / 6 Scrum V 1.0 1. Wieso Scrum Die Entwicklung

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

Wie misst man Qualität?

Wie misst man Qualität? Software Systems Engineering Wie misst man Qualität? Dr. Privat-Doz. A Herrmann Institut Software Systems Engineering Ziele dieses Workshops Workshop Wie misst man Qualität? Methoden lernen: Herleitung

Mehr

Scrum mit User Stories

Scrum mit User Stories Ralf Wirdemann Scrum mit User Stories HANSER Inhaltsverzeichnis 1 Einführung 1 1.1 Warum dieses Buch? 2 1.2 Struktur und Aufbau 3 1.3 Dankeschön 5 1.4 Feedback 5 2 Beispiel: Scrumcoaches.com 7 2.1 Das

Mehr

extreme Programming (XP)

extreme Programming (XP) Softwaretechnik SS2005 Tobias Giese Masterstudiengang Informatik HS-Harz Agenda Allgemeines Vorgehensmodell Kommunikation und Arbeitsphilosophie Entwicklungsphasen / Extreme Rules Planung Entwurf Implementierung

Mehr

Softwarequalität - Qualitätsmodelle

Softwarequalität - Qualitätsmodelle Softwarequalität - Qualitätsmodelle Proseminar IT-Kennzahlen und Codemetriken Clara Lange 17.05.2010 TU München Inhalt 1. Was ist Softwarequalität? 2. Sichten auf Softwarequalität 3. Messen von Qualität

Mehr

Agile Software Development

Agile Software Development Dipl. Wirtsch. Ing. Alexander Werth Methoden der Softwareentwicklung 6-1 Agile Manifest Individuen und Interaktion statt Prozessen und Tools. Funktionierende Software statt umfangreicher Dokumentation.

Mehr

Softwaretechnik WS 2013/14. Fomuso Ekellem

Softwaretechnik WS 2013/14. Fomuso Ekellem WS 2013/14 Organisatorisches Dozentin : Ango (Raum 2.250) Fragen und Übungen: mathe_ekellem@yahoo.com (Nur hier, sonst wird nicht bewertet) Folien: http://www.gm.fh-koeln.de/~afomusoe/softwaretechnik.html

Mehr

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Insert picture and click Align Title Graphic. Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Dr. Dieter Lederer, Geschäftsführer Vector Consulting Services GmbH

Mehr

Testmanagement im agilen Entwicklungsprozess

Testmanagement im agilen Entwicklungsprozess Testmanagement im agilen Entwicklungsprozess Unser Beratungsangebot für die effiziente Abwicklung von Projekten: n Anforderungen erkennen n Software-Qualität steigern n Teams zum Erfolg führen Unser Erfolgskonzept:

Mehr

Scrum Team Diagnose. Gibt es sonst noch etwas, was du zur Rolle des Product Owners sagen möchtest?

Scrum Team Diagnose. Gibt es sonst noch etwas, was du zur Rolle des Product Owners sagen möchtest? Scrum Rollen Product Owner (PO) Der PO ist klar definiert Der PO übersetzt Anforderungen in klare Backlog Items Der PO ist ermächtigt, Backlog Items zu priorisieren Der PO verfügt über das Fachwissen,

Mehr

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 Agiles Vorgehen 2 Agiles Vorgehen 3 WAS BEDEUTET AGIL Abstimmung über Ziel (nicht konkretes Entwicklungsergebnis)

Mehr

There is no security on this earth. Na und? General Douglas MacArthur. Alfred E. Neumann

There is no security on this earth. Na und? General Douglas MacArthur. Alfred E. Neumann There is no security on this earth. Na und? General Douglas MacArthur Alfred E. Neumann Anwendungen verursachen Unsicherheit Ca. ¾ aller Schwachstellen stammen aus Anwendungen. Cryptography 0% Application

Mehr

Kurzübersicht Unified Process und Agile Prozesse

Kurzübersicht Unified Process und Agile Prozesse Kurzübersicht Unified Process und Agile Prozes Rainer Schmidberger schmidrr@informatik.uni-stuttgart.de Copyright 2004, Rainer Schmidberger, Universität Stuttgart, Institut für Softwaretechnologie, Abt.

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Software Engineering (SE) 2) Phasenübergreifende Verfahren

Software Engineering (SE) 2) Phasenübergreifende Verfahren Software Engineering (SE) 2) Phasenübergreifende Verfahren Prof. Dr. Anja Metzner Hochschule Augsburg, Fakultät für Informatik Kontakt: anja.metzner@hs-augsburg.de Studiengang IBac 1 (Stand: 01.10.2014),

Mehr

Software-Dokumentation im agilen Umfeld. Marion Bröer, parson communication

Software-Dokumentation im agilen Umfeld. Marion Bröer, parson communication Software-Dokumentation im agilen Umfeld Marion Bröer, parson communication parson communication Software- und Prozessdokumentation Wissensmanagement Wikis und XML-basierte Dokumentation Schulungen und

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird.

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. AGILO HOWTO Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. ROLLEN IM TEAM In Scrum hat jedes Teammitglied eine

Mehr

PQ4Agile Agiler Referenzprozess

PQ4Agile Agiler Referenzprozess PQ4Agile Agiler Referenzprozess ARBEITSPAKET 1.1 KONSORTIUM Projekt Förderprogramm PQ4Agile KMU Innovativ Förderkennzeichen 01IS13032 Arbeitspaket Fälligkeit 31.07.2014 Autor Status Klassifikation AP1.1

Mehr

Service Transition. Martin Beims. WKV SS13 Karsten Nolte. Mittwoch, 19. Juni 13

Service Transition. Martin Beims. WKV SS13 Karsten Nolte. Mittwoch, 19. Juni 13 Service Transition Martin Beims WKV SS13 Karsten Nolte Inhalt Einführung & Ziele Transition Planning & Support Change Management Service Asset & Configuration Management Release & Deployment Management

Mehr

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG YAKINDU Requirements Requirements Engineering, Management and Traceability with Eclipse Lars Martin, itemis AG Agenda YAKINDU Requirements Motivation: Warum Requirements Engineering? Grundlagen: Requirements

Mehr

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm

Wasserfall, «Death March», Scrum und agile Methoden. 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Wasserfall, «Death March», Scrum und agile Methoden 08. Dezember 2011 Embedded Software Engineering Kongress Urs Böhm Übersicht Warum Projektmanagement? Gängige SW Entwicklungsprozesse Wasserfall V-Modell

Mehr

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl

SCRUM. Scrum in der Software Entwicklung. von Ernst Fastl SCRUM Scrum in der Software Entwicklung von Ernst Fastl Agenda 1. Die Entstehung von Scrum 2. Überblick über den Prozess 3. Rollen 4. Meetings 5. Artefakte 6. Fragen & Antworten Agenda 1. Die Entstehung

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

mimacom path Ihr Nutzen www.mimacom.com

mimacom path Ihr Nutzen www.mimacom.com ist ein Lösungspaket, mit dem sich das ganze Application Lifecycle Management abdecken lässt: Vom Requirements Engineering über die agile Abwicklung von Projekten bis hin zum Service Management. Der ganzheitliche

Mehr

Wahlpflichtmodul Projekt I Softwareprojekt I

Wahlpflichtmodul Projekt I Softwareprojekt I Wahlpflichtmodul Projekt I Softwareprojekt I Dipl. Inf. Andrea Meyer SCRUM in Detail Dipl. Inf. Andrea Meyer WIEDERHOLUNG 4 Prinzipien von SCRUM Zerlegung Transparenz Anpassung Überprüfung WIEDERHOLUNG

Mehr

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management

Mehr

Code-Quality-Management

Code-Quality-Management Code-Quality-Management Technische Qualität industrieller Softwaresysteme transparent und vergleichbar gemacht von Frank Simon, Olaf Seng, Thomas Mohaupt 1. Auflage Code-Quality-Management Simon / Seng

Mehr

extreme Programming (XP) Hermann Götz Sergij Paholchak Agenda Was ist XP? Grundprinzipien Der Entwicklungsprozess Die Projektplanung Praktiken Vorteile und Nachteile Wann macht XP Sinn für ein Projekt?

Mehr

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Die Bearbeitungszeit der Klausur beträgt 90 Minuten. Es sind alle

Mehr

Bekannte Tools in einem agilen Ansatz. Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013

Bekannte Tools in einem agilen Ansatz. Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013 Bekannte Tools in einem agilen Ansatz Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013 Vorher Lange Planungszeiten und Releasezyklen Manche Features brauchten lange und wurden nicht gebraucht

Mehr

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012 Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel Verglühte die Raumfähre Columbia durch einen unflexiblen Projektmanagementprozess? Rückblick: 2003 verglühte

Mehr

MSP: Methoden des Software-Entwicklungsprozesses

MSP: Methoden des Software-Entwicklungsprozesses WS 2005/06 Mastermodul CS 5002 MSP: Methoden des Software-Entwicklungsprozesses Teamentwicklung extreme Programming Projekttagebuch Prof. Dr. Klaus Quibeldey-Cirkel Fachhochschule Gießen-Friedberg Forming

Mehr

Merkblatt des Fachgebiets Empirische Medienforschung und Politische Kommunikation zur Anfertigung von Masterarbeiten

Merkblatt des Fachgebiets Empirische Medienforschung und Politische Kommunikation zur Anfertigung von Masterarbeiten Merkblatt des Fachgebiets Empirische Medienforschung und Politische Kommunikation zur Anfertigung von Masterarbeiten Die hier festgelegten Regeln gelten nur für Arbeiten, die von Mitgliedern dieses Fachgebiets

Mehr

Wi W s i sens n ch c a h ft f l t ilc i h c e h s s A rbe b it i en Hans-Peter Wiedling 1

Wi W s i sens n ch c a h ft f l t ilc i h c e h s s A rbe b it i en Hans-Peter Wiedling 1 Wissenschaftliches Arbeiten Hans-Peter Wiedling 1 Mit Ihrer wissenschaftlichen Arbeit dokumentieren Sie die eigenständige Einarbeitung in eine Aufgaben-/Problemstellung sowie die methodische Erarbeitung

Mehr

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Ottostr. 15 96047 Bamberg Tel. +49/951/98046200 Fax +49/951/98046150 email: info@softcondev.de www: softcondev.de INHALT Vorwort Diese

Mehr

REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1

REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1 REQUIREMENTS ENGINEERING KONSTRUKTIVE QS REQUIREMENTS ENGINEERING 1 QUALITÄT FÜR SIE Qualität zeigt sich in Ergebnissen und Erfolgen. Sie hängt von der jeweiligen Problemstellung ab, deshalb sehen wir

Mehr

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer Agiles Projektmanagement erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011 Thomas Hemmer Chief Technology Officer thomas.hemmer@conplement.de conplement AG, Nürnberg 2 conplement

Mehr

ralf WIRDEMANN SCRUM MIT USER STORIES 2. Auflage

ralf WIRDEMANN SCRUM MIT USER STORIES 2. Auflage ralf WIRDEMANN SCRUM MIT USER STORIES 2. Auflage Wirdemann Scrum mit User Stories vbleiben Sie einfach auf dem Laufenden: www.hanser.de/newsletter Sofort anmelden und Monat für Monat die neuesten Infos

Mehr

Universität zu Köln Institut für Historisch-Kulturwissenschaftliche Informationsverarbeitung Virtuelle Forschungsumgebungen Dozent: Prof. Dr. phil.

Universität zu Köln Institut für Historisch-Kulturwissenschaftliche Informationsverarbeitung Virtuelle Forschungsumgebungen Dozent: Prof. Dr. phil. Universität zu Köln Institut für Historisch-Kulturwissenschaftliche Informationsverarbeitung Virtuelle Forschungsumgebungen Dozent: Prof. Dr. phil. Manfred Thaller WS 2010/11 Referentin: Sanja Wiechmann

Mehr

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches Dieses Buch beschreibt das Wesen von Scrum die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen. Was ist das Wesen

Mehr

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Klassische vs. agile Methoden der Softwareentwicklung

Klassische vs. agile Methoden der Softwareentwicklung Klassische vs. agile Methoden der Softwareentwicklung Vorgetragen am 03. November 2004 durch Jonathan Weiss Emel Tan Erstellt für SWT Methoden und Werkzeuge zur Softwareproduktion Agenda I. Einleitung

Mehr

Grundlagen der Anforderungsanalyse. 28. Oktober 2014

Grundlagen der Anforderungsanalyse. 28. Oktober 2014 Grundlagen der Anforderungsanalyse 28. Oktober 2014 Überblick Wie analysiert man die Anforderungen an ein neues Softwaresystem? Welche Methoden und Techniken gibt es? Welche Probleme kann es bei der Anforderungserfassung

Mehr

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Wasserfall vs. Agile: Eine Erfolgsstory 2 Umsetzung agiler Prinzipien Entwicklungsprozess 2009 30.6% 13.4% 20.6% 35.4% Agil Iterativ

Mehr

Software-Praktikum. Gabriele Taentzer Philipps-Universität Marburg Sommersemester 2015

Software-Praktikum. Gabriele Taentzer Philipps-Universität Marburg Sommersemester 2015 Software-Praktikum Gabriele Taentzer Philipps-Universität Marburg Sommersemester 2015 Überblick Was ist das Ziel des Praktikums? Wie wird das Praktikum durchgeführt? Was wird bewertet? Taentzer Software-Praktikum

Mehr

Scrum. Eine Einführung

Scrum. Eine Einführung Scrum Eine Einführung Scrum-Charakteristika einfache Regeln wenige Rollen Pragmatismus statt Dogmatik iteratives Vorgehen Scrum auf einer Seite erklärt 3 Rollen für direkt am Prozeß beteiligte 1) Product

Mehr

HWR-Chat Ein Chat für Studenten, Dozenten und interne Mitarbeiter der Hochschule für Wirtschaft und Recht

HWR-Chat Ein Chat für Studenten, Dozenten und interne Mitarbeiter der Hochschule für Wirtschaft und Recht Christian Gebauer, Sebastian Große, Benjamin Pfeiffer, Nico Smeenk, Jonathan Wiens Im Auftrag von Frau Prof. Dr. Dagmar Monett-Díaz HWR-Chat Ein Chat für Studenten, Dozenten und interne Mitarbeiter der

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

AustroFeedr. Pushing the Realtime Web. Projektplan. erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10.

AustroFeedr. Pushing the Realtime Web. Projektplan. erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10. AustroFeedr Pushing the Realtime Web Projektplan erstellt von: DI Klaus Furtmüller, DI Wolfgang Ziegler Version 1.0 Datum: 05.10.2010 gefördert durch die Internet Privatstiftung Austria (IPA) 1 Projektbeschreibung

Mehr