| |
Donnerstag, 22. November 2007
Qualitätssicherung Geschrieben von Projektleiter
in Dokumentation um
18:37
Kommentare (0) Trackbacks (0) Qualitätssicherung
Art und Umfang der Qualitätssicherung hängen immer vom Projekt ab. Sinnvollerweise wurde die Qualitätssicherung schon bei der Auftragsvergabe vereinbart, dann gibt es an dieser Stelle nicht mehr viel zu interpretieren.
Abhängig davon was mit der Qualitätssicherung überhaupt erreicht werden soll sind zwei Fälle zu unterscheiden: Die konstruktive Qualitätssicherung arbeitet vorausschauend und trägt schon während der laufenden Arbeit zur Qualitätssicherung bei. Man kann damit versuchen Risiken für ein Scheitern des Projekts schon im Vorfeld auszuschließen. Die analytische Qualitätssicherung ist eine messende Qualitätssicherung und misst die Qualität des Projekts oder Produkts zu festgelegten Zeitpunkten. Diese Zeitpunkte sind üblicherweise durch Meilensteine schon im Pflichtenheft vereinbart. Spätestens der Test vor der Abnahme sollte vereinbart sein und als analytische Qualitätssicherung auch dokumentiert werden (z.B. Messprotokolle, Checkliste). Auf jeden Fall will der Prüfer von der IHK eine Qualitätssicherung sehen, auch wenn der Auftraggeber sie nicht gefordert hat, zumindest soll der Auszubildende daran gedacht haben. Diese Qualitätssicherung muss nachvollziehbar sein, es reicht natürlich nicht aus zu schreiben "ich habe alles ausprobiert und war zufrieden". Wenn Testdaten eingesetzt wurden, sollten diese auch in Art und Umfang erkennbar sein damit nachvollziehbar ist, ob sie den Testzweck erfüllen. Die Qualitätssicherung sollte ehrlich und angemessen sein, ein- bis zwei Stunden darf man dafür mindestens in das Projekt verplanen. Beim Fachinformatiker Anwendungsentwicklung auch deutlich länger, da es dem Auftraggeber meist nicht möglich ist zu erkennen, welche Maßnahmen der Qualitätssicherung erforderlich und sinnvoll sind. Dienstag, 20. November 2007Geschichte der UML
In den 90er Jahren entstand als Reaktion auf zahlreiche Vorschläge für Modellierungssprachen und -methoden UML. Damit sollte die damals hochaktuelle objektorientierte Softwareentwicklung unterstützt werden. Erfinder der UML waren insbesondere Grady Booch, Ivar Jacobson und James Rumbaugh (auch als "die drei Amigos" bekannt, wohl in Anlehnung an den sehr mäßigen Spielfilm).
Bei ihrer Tätigkeit im Unternehmen Rational Software entstand der Ansatz, die vorhandenen Methoden strukturiert zusammenzuführen. Daraus entstand die UML, zur Standardisierung, Pflege und Weiterentwicklung wurde die Sprache wurde an OMG übergeben, die die Sprache am 19. November 1997 als Standard akzeptierte. Ab August 1999 strebte die OMG dann die Weiterentwicklung an, verschiedene Gruppen und Einzelpersonen reichten Entwürfe ein.und im Oktober 2002 konnten alle Vorschläge für die UML 2.0 Infrastructure und die UML 2.0 Superstructure präsentiert werden. Die Hauptschwierigkeit bestand nun darin, die unterschiedlichen Entwürfe zu einer Spezifikation zu verbinden. Erst im Februar 2007 konnte die OMG die jetzt aktuelle Version UML 2.1.1 veröffentlichen, die aber noch nicht von allen UML-Tools unterstützt wird. Montag, 29. Oktober 2007Lastenheft
Das Lastenheft stellt eine grobe Produktskizze für ein zu erstellendes Software-Produkt dar. Damit ist das Lastenheft vereinfachte Form des Pflichtenhefts. Da es nicht detailliert ausfallen soll, muss es vom Umfang so knapp wie erforderlich gehalten werden, meist werden nur wenige Seiten benötigt.
Es wird nicht beschrieben, "wie" etwas gemacht werden soll, sondern nur "was" die neue Software leisten soll. Die Basisfunktionen der neuen Software und ihr Sinn muss deutlich herausgearbeitet werden. Da das Lastenheft die Grundlage für Entscheider darstellt, muss es sprachlich so gehalten sein, dass diese es verstehen und vor allem die Argumente nachvollziehen können. Wenn der Auftraggeber eine Fachsprache verwendet, sollten die entsprechenden Begriffe auch an den erforderlichen Stellen eingesetzt werden, hier sollte eine Fachkraft der Branche gegebenenfalls noch einmal Korrektur lesen. Hier sagt ein Bild auch oft mehr als 1000 Worte - eine Zeichnung kann viele Abläufe verdeutlichen! Auch Tabellen sollten eigesetzt werden, um Werte übersichtlich zu präsentieren. Zahlenreihen sollten in grafischer Darstellung visualiert werden. Die Gliederung des Lastenhefts ist nicht verbindlich geregelt und es gibt verschiedene Empfehlungen dazu: Balzert empfiehlt Zielbestimmung: Was soll die Software können? Produkteinsatz: Wer soll die Software einsetzen? Produktfunktionen: Welches sind die Hauptfunktionen? Produktdaten: Welche Daten werden verarbeitet? Produktleistungen: Wie schnell, umfassend, genau? Qualitätsanforderungen: Wie zuverlässig, portabel...? Ergänzungen: Was sonst noch? Montag, 29. Oktober 2007
Projektstudie (feasibility study) Geschrieben von Projektleiter
in Projektphasen um
19:15
Kommentare (3) Trackbacks (0) Projektstudie (feasibility study)
Die Projektstudie wie sie nach DIN 69905 richtig heißt, auch Machbarkeitsstudie oder auf plattdeutsch auch "feasibility study" genannt, steht am Anfang größerer Projekte als erste Projektphase, teilweise noch vor dem Kick-off. Über die Tätigkeiten und Ergebnisdokumente gibt es in der Literatur keine Einigkeit. da die Gestaltung dieser Phase sehr von der Situation abhängt.
Mit der Projektstudie soll das Risiko für eine Erreichen des Projektziels geprüft werden, wenn nicht sicher ist ob dies überhaupt möglich ist. So kann man versuchen herauszubekommen, mit welchen Aufwand (zeitlich und damit auch finanziell) der Projekt realisiert werden kann. Rein organisatorisch bringt die Projektstudie Ordnung ins anfängliche Chaos. Im Hauptteil der Projektstudie steht die Machbarkeitsprüfung: Hier wird die organisatorische Umsetzung und wirtschaftliche Machbarkeit (z.B. Kostenrahmen, Finanzierung), aber auch die technische Machbarkeit und die Verfügbarkeit von Ressourcen (Mitarbeiter, Räume, Geräte und Zeit) geklärt. Für die Projektstudie wird üblicherweise ein strammes Zeitfenster angesetzt, nach deren die Untersuchungen abgeschlossen sein müssen. Ist das Ergebnis dieser Studie negativ muss das Projekt abgelehnt oder komplett geändert werden. Nach der Machbarkeitsstudie fällt auf jeden Fall die Entscheidung "stop-or-go". Im Bereich der Software-Entwicklung hat die Projektstudie auch noch eine weitere Funktion neben der eigentlichen Untersuchung der Machbarkeit, nämlich festzulegen, was die Software überhaupt leisten soll. Neben den Anforderungen an die Software und die Funktionen sind auch die Gestaltung des Benutzer-Interfaces der Inhalt einer Vorstudie zu einer Software-Entwicklung. Ergebnis der Studie sollte daher auch ein Lastenheft sein. Dazu sind Ausschreibungsunterlagen und gesetzliche Vorgaben zu beachten, es muss der Markt oder die bestehende Software analysiert werden sowie Interviews mit Anwendern und späteren Fachleuten geführt werden. Montag, 29. Oktober 2007
Wasserfall-Modell Geschrieben von Projektleiter
in Projektphasen um
09:16
Kommentare (4) Trackbacks (0) Wasserfall-Modell
Das Wasserfallmodell ist eine klassische Vorstellung von der Aufeinanderfolge von Projektphasen im Software-Engineering, der Softwareentwicklungsprozess in Phasen aufgeteilt. Der Name kommt daher, weil man dabei davon ausgeht, dass Ergenisse einer Phase wie bei einem Wasserfall immer als bindende Vorgaben für die nächst tiefere Phase eingehen.
Das Problem des Wasserfallmodells ist jedoch, dass es nur dann problemlos eingesetzt werden kann, wenn sich die Anforderungen und Kundenwünsche an das Projekt und das fertige Software-Produkt schon in der Planungsphase präzise beschreiben lassen. Ende jeder Projektphase sind dabei sogenannte Meilensteine, Sitzungen an denen die Ergebnisse der Projektphasen dokumentiert werden. Die Phasen können dabei in ihrer Anzahl und Bezeichnung unterschiedlich ausfallen, aber immer findet man die grafischen Darstellung der fünf bis sechs als Kaskade angeordneten Phasen: ![]() Davon gibt es einige Varianten, beispielsweise gehört in bei der Integration gehört auch ein Test zur Qualitätssicherung mit dazu. Zum Kickoff kann es nur ein kurzes Meeting geben, diese Phase kann aber auch die Durchführung einer Studie bedeuten, nach der erst weiter über das Projekt entschieden wird. In der Praxis überschneiden sich Projektphasen und es ist auch immer wieder mal erforderlich, einen Schritt zurück zu gehen. Dies kann das Wasserfallmodell mit dem Ansatz, dass die Phasen nacheinander ablaufen und voneinander sauber abgrenzbar sind nicht mehr abbilden. Damit ist das Wasserfallmodell nur auf einfache Projekte anwendbar und unflexibel gegenüber Änderungen. Es ist nur dann verwendbar wenn es möglich ist, schon früh die Anforderungen festzuschreiben. Werden Fehler erst spät erkannt, müssen sie mit erheblichem Aufwand entfernt werden. Wegen der gravierenden Nachteile des Wasserfallmodells, die meist erhöhten finanzielle Aufwand bedeuten, hat das Wasserfallmodell heute kaum noch praktischen Wert und wurde in der IT-Industrie durch eine Vielfalt alternativer oder ergänzender Vorgehensweisen ersetzt. |
SucheNavigationKategorienBlogroll |
Administration :: Impressum :: Geoinformatik :: Linux installieren :: viertelzackvorschnirk