Vollständigkeit der Anforderungen - Innovationsnetzwerk Region ...
Vollständigkeit der Anforderungen - Innovationsnetzwerk Region ...
Vollständigkeit der Anforderungen - Innovationsnetzwerk Region ...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Software Lifecycle Management<br />
in <strong>der</strong> Praxis<br />
Frank Wuttke – Compra GmbH<br />
wuttke@compra.de
Was tun wir?<br />
• Herstellung von Standardsoftware<br />
• Herstellung von Individualsoftware<br />
• Anpassung von Software (Customizing)<br />
• Consulting/Konzeption (8), Architektur (2),<br />
Programmierung (30), Support , Hotline,<br />
Wartung (10)
Software Lebenszyklus<br />
• Als Softwarelebenszyklus wird die gesamte Lebensdauer eines<br />
Software-Produktes von seiner Entwicklung über seinen Betrieb<br />
bis hin zu seiner „Außerbetriebnahme“ bezeichnet. (1)<br />
Anfor<strong>der</strong>ung,<br />
Idee<br />
Spezifikation<br />
Implementation,<br />
Erprobung<br />
(1) Rainer Dumke: Software Engineering, Vieweg Verlag, ISBN 3-528-25355-X, 2001<br />
Auslieferung Anwendung Wartung
Von <strong>der</strong> Anfor<strong>der</strong>ung zur Entwicklung
Support/Wartung
Change Request
Checkliste Funktionale Anfor<strong>der</strong>ungen<br />
Spezifische funktionale Anfor<strong>der</strong>ungen<br />
• Sind alle Eingaben des Systems definiert – einschließlich Datenquelle, Genauigkeit,<br />
Wertebereich und Häufigkeit?<br />
• Sind alle Ausgaben des Systems festgelegt worden – einschließlich Ausgabeziel,<br />
Genauigkeit, Wertebereich, Häufigkeit und Format?<br />
• Sind die Ausgabeformate aller Webseiten, Berichte und so weiter definiert?<br />
• Sind sämtliche externen Hardware- und Softwareschnittstellen festgelegt?<br />
• Sind alle externen Kommunikationsschnittstellen definiert, einschließlich<br />
Handshake, Fehlerüberprüfung und Übertragungsprotokolle?<br />
• Sind alle Aufgaben, die <strong>der</strong> Benutzer durchführen können möchte, festgelegt<br />
worden?<br />
• Stehen die Ein- und Ausgangsdaten für jede Aufgabe fest?
Checkliste Nichtfunktionale Anfor<strong>der</strong>ungen<br />
Spezifische nichtfunktionale Anfor<strong>der</strong>ungen<br />
• Ist die Antwortzeit (wie sie <strong>der</strong> Benutzer benötigt) für sämtliche notwendigen<br />
Operationen bestimmt worden?<br />
• Ist darüber hinaus ein Zeitverhalten festgelegt worden – etwa Verarbeitungszeit,<br />
Datenübertragungsgeschwindigkeit o<strong>der</strong> Systemdurchsatz?<br />
• Wurde eine Sicherheitsstufe angegeben?<br />
• Ist die Zuverlässigkeit festgelegt worden? Wurden die Folgen von Softwareausfällen<br />
abgeschätzt? Welche Daten müssen unbedingt vor den Folgen solcher Fehler geschützt<br />
werden? Welche Strategien bestehen für Fehlererkennung und –behebung?<br />
• Wurden Mindestgrößen für Hauptspeicher und freien Festplattenplatz angegeben?<br />
• Welche Aussagen wurden zur Wartung des Systems getroffen? Wie lässt sich das System<br />
an an<strong>der</strong>e Betriebssysteme o<strong>der</strong> an<strong>der</strong>e Softwareschnittstellen anpassen? Wie lassen<br />
sich Funktionsumfang, Genauigkeit und Geschwindigkeit anpassen?<br />
• Steht schwarz auf weiß fest, wann das System als Erfolg zu betrachten ist und wann als<br />
Misserfolg?
Checkliste Qualität <strong>der</strong> Anfor<strong>der</strong>ungen<br />
Qualität <strong>der</strong> Anfor<strong>der</strong>ungen<br />
• Sind die Anfor<strong>der</strong>ungen in <strong>der</strong> Sprache des Benutzers festgehalten? Ist dies auch die Ansicht <strong>der</strong><br />
Benutzer?<br />
• Gibt es Wi<strong>der</strong>sprüche zwischen den einzelnen Anfor<strong>der</strong>ungen?<br />
• Wurden annehmbare Kompromisse zwischen den Attributen des Systems festgelegt – etwa zwischen<br />
Robustheit und Genauigkeit?<br />
• Haben Sie es vermieden, zugleich einen Entwurf zu liefern?<br />
• Zeichnen sich sämtliche Anfor<strong>der</strong>ungen durch eine ähnliche Detailtiefe aus? Müssen Anfor<strong>der</strong>ungen<br />
detaillierter festgehalten werden? Ist wie<strong>der</strong>um an an<strong>der</strong>er Stelle weniger Detailfreude angebracht?<br />
• Wurden die Anfor<strong>der</strong>ungen so klar formuliert, dass eine an<strong>der</strong>e Arbeitsgruppe damit problemlos<br />
weiter arbeiten kann? Ist dies auch die Ansicht <strong>der</strong> Entwickler?<br />
• Sind wirklich alle Punkte für die Lösung des Problems von Bedeutung? Lässt sich je<strong>der</strong> Punkt zu<br />
seinem Ursprung im Problem zurückverfolgen?<br />
• Lässt sich je<strong>der</strong> einzelne Punkt testen? Lässt sich mit unabhängigen Testmethoden festlegen, ob alle<br />
Anfor<strong>der</strong>ungen erfüllt worden sind?<br />
• Wurden alle möglichen Än<strong>der</strong>ungen an den Anfor<strong>der</strong>ungen angeführt – einschließlich <strong>der</strong><br />
Wahrscheinlichkeit solcher Anfor<strong>der</strong>ungen?
Checkliste <strong>Vollständigkeit</strong> <strong>der</strong> Anfor<strong>der</strong>ungen<br />
<strong>Vollständigkeit</strong> <strong>der</strong> Anfor<strong>der</strong>ungen<br />
• Steht fest, wo welche Anfor<strong>der</strong>ungen fehlen?<br />
• Sind die Anfor<strong>der</strong>ungen insoweit vollständig, dass ein Produkt, das all diesen<br />
Anfor<strong>der</strong>ungen genügt, als annehmbar angesehen werden kann?<br />
• Haben Sie bei irgendwelchen Anfor<strong>der</strong>ungen Bedenken? Können einige<br />
Anfor<strong>der</strong>ungen etwa gar nicht erfüllt werden und stehen nur da, weil Ihr Chef o<strong>der</strong><br />
<strong>der</strong> Kunde es so will?
Checkliste Softwarearchitektur<br />
Spezifische Punkte <strong>der</strong> Architektur<br />
• Ist die gesamte Organisation des Programms klar und einleuchtend? Ist die<br />
Architektur übersichtlich dargestellt und gut begründet?<br />
• Sind alle wichtigen Bausteine sorgfältig definiert, einschließlich ihrer<br />
Verantwortungsbereiche und Schnittstellen zu an<strong>der</strong>en Bausteinen?<br />
• Sind die wichtigsten Klassen beschrieben und gut begründet?<br />
• Ist <strong>der</strong> Datenentwurf beschrieben und gut begründet?<br />
• Sind Aufbau und Inhalt <strong>der</strong> Datenbanken beschrieben?<br />
• Sind alle wichtigen Geschäftsregeln auf geführt und ist ihre Bedeutung für das<br />
System beschrieben?<br />
• Ist eine Strategie für das Aussehen <strong>der</strong> Benutzeroberfläche beschrieben?<br />
• Ist die Benutzeroberfläche so modularisiert, dass Än<strong>der</strong>ungen sich nicht auf das<br />
übrige Programm auswirken?
• Gibt es eine Strategie für die Behandlung von Ein- und Ausgaben und wurde sie<br />
begründet?<br />
• Wurde <strong>der</strong> Ressourcenbedarf abgeschätzt? Wurde die Strategie für die Verwaltung<br />
knapper Ressourcen (zum Beispiel Threads, Datenbankverbindungen, Handles,<br />
Netzwerkbandbreite) dokumentiert und begründet?<br />
• Sind die Sicherheitsanfor<strong>der</strong>ungen <strong>der</strong> Architektur beschrieben?<br />
• Gibt die Architektur für jede Klasse, jedes Subsystem o<strong>der</strong> jeden Funktionsbereich den<br />
Spielraum an, in dem sich Geschwindigkeit und Speicherbedarf bewegen dürfen?<br />
• Beschreibt die Architektur, wie Skalierbarkeit erreicht wird?<br />
• Ist eine Strategie für das Thema Internationalisierung/Lokalisierung beschrieben?<br />
• Wird eine konsistente Fehlerbehandlungsstrategie definiert?<br />
• Wird <strong>der</strong> Ansatz für die Fehlertoleranz definiert (falls erfor<strong>der</strong>lich)?<br />
• Wurde die technische Machbarkeit aller Elemente des Systems überprüft?<br />
• Wird eine Strategie gegen Overengineering definiert?
Checkliste Use-Case<br />
Organisation und Standards<br />
• Ist <strong>der</strong> Anwendungsfall ein separater, eigenständiger Prozess?<br />
• Ist <strong>der</strong> Anwendungsfall eher allgemein beschrieben, o<strong>der</strong> ist es ein spezifisches<br />
Szenario?<br />
• Ist <strong>der</strong> Anwendungsfall frei von Implementierungs- und Designdetails?<br />
• Ist <strong>der</strong> Anwendungsfall beschränkt auf 10 Schritte o<strong>der</strong> weniger?<br />
• Kann man anhand des Namens schon erkennen, was mit diesem<br />
Dokument/Anwendungsfall erreicht werden soll?
<strong>Vollständigkeit</strong> und Korrektheit<br />
• Sind die Ziele aller Beteiligten berücksichtigt worden?<br />
• Sind alle Beteiligten repräsentiert (direkt <strong>der</strong> indirekt)?<br />
• Sind alle bekannten alternativen Arbeitsabläufe dokumentiert?<br />
• Sind alle bekannten Ausnahmebedingungen dokumentiert?<br />
• Sind die einzelnen Schritte für jeden Ablauf vollständig?<br />
• Ist <strong>der</strong> Key User für jeden Anwendungsfall auch geeignet, um die Aufgabe<br />
zu erfüllen?<br />
• Ist je<strong>der</strong>, im Anwen<strong>der</strong>fall definierte Arbeitsablauf auch praktikabel?<br />
• Ist je<strong>der</strong> Schritt des Anwen<strong>der</strong>falles auch geeignet, um das Ziel zu<br />
erreichen?<br />
• Ist sicher gestellt, dass für den Key User ein wahres Verhalten (truebehavior)<br />
definiert wurde?
Eindeutigkeit und Klarheit<br />
• Ist das Ziel, o<strong>der</strong> <strong>der</strong> zu messende Wert für diesen Anwendungsfall klar?<br />
• Ist klar, welcher Akteur bzw. welche Akteure von diesem Anwendungsfall<br />
profitieren?<br />
• Ist je<strong>der</strong> allgemeine Handlungsablauf in den separaten Anwendungsfällen<br />
berücksichtigt?<br />
• Ist je<strong>der</strong> Arbeitsschritt für jeden Arbeitsablauf klar beschrieben und eindeutig?<br />
• Ist je<strong>der</strong> Ablauf im Anwendungsfall verifizierbar?
Organisationshilfen<br />
• Vision<br />
• Unternehmensrichtlinien und Softwareentwicklungsrichtlinien<br />
• Architekt<br />
• Entwicklungsleiter<br />
• Datenbank-Gremium<br />
• UI-Gremium<br />
• Konzeptions-Gremium<br />
– Consultants<br />
– Support
Werkzeuge<br />
• Sourcecodeverwaltung<br />
• Ticketsystem<br />
• Reporting/Controlling<br />
• Projektmanagement<br />
• Dokumentationsplattform<br />
• Abrechnungssystem
Microsoft Team Foundation Server<br />
• Sourcecodeverwaltung, Ticketsystem, Reporting/Controlling, Projektmanagement<br />
• Demo:
Flare<br />
• Erstellung <strong>der</strong> Online-Hilfe, Dokumentation und WIKI aus einer Quelle<br />
• Forum, Statistiken<br />
• Demo<br />
• Wiki
Vielen Dank!<br />
• Ist die Software, die Sie herstellen, auch wirklich die, die Ihr Kunde braucht und<br />
haben möchte?<br />
• Fragen Sie ihn das (zumindest hin und wie<strong>der</strong>)?<br />
Quellen: Code Complete, Steve McConnell, Microsoft Press, ISBN 3-86063-593-X
Change language