© Excellent backgrounds/Shutterstock.com
Java Magazin
Wissen fürs Projekt oder für die Schublade?

Software-Design-Dokumente

Software Design Descriptions/Documents (SDD) [1] sind für die erfolgreiche Entwicklung und Wartung von Software unentbehrlich. Wirklich? Wer oder was beeinflusst deren Sinn und Einsatz im Projekt? Was ist eigentlich zu beachten, damit sie nicht schon während des Projekts zum Papiertiger werden und einen Nutzen darstellen können? Eine pragmatische Übersicht.

Berthold Schulte


Ein Dokument dient der schriftlichen Vermittlung von Information und Wissen zwischen Menschen. Software-Design-Dokumente beinhalten im Speziellen das Wissen über eine abstrakte Lösung zum Aufbau eines Stücks Software. Die darin dargestellte Information ist allerdings nur einer sehr kleinen Leserschaft zugänglich – da Wissen aus dem Bereich der Softwareentwicklung noch nicht zum Allgemeinwissen gehört, technisch komplex ist und eine eigene Sprache besitzt.

Die Zielgruppen

Wer gehört zu dieser Leserschaft, welche Erwartungen hat sie und welchen Einfluss hat sie auf das Dokument? Neben den Softwareentwicklern sind Tester, Requirement Engineers, Businessanalysten (BA) sowie der Kunde, die Projektleitung und die IT-Abteilung potenzielle Leser, wenn auch mit einem unterschiedlichen Fokus auf das, was sie aus dem Dokument erfahren wollen.

Softwareentwickler und Dev-Peers: Ein Softwareentwickler hat in der Regel die „engste“ Beziehung zu einem SDD. Einerseits erstellen Softwareentwickler das Design und die Dokumente oft selbst, andererseits arbeiten sie aktiv und ständig damit, da es ihre Arbeitsvorlage ist. Eben diese direkte Beteiligung an der Umsetzung verpflichtet den Entwickler auch zur Wahrung der Aktualität des SDDs. Hält er Änderungen am Design für nötig oder ergeben sich zwingend Gründe dafür, muss er sie in irgendeiner Form niederschreiben. Ansonsten gehen diese Änderungen in der Menge des Codes unter. Arbeitet er mit einem SDD eines zum Beispiel erfahreneren Entwicklers, so muss eine gute und ständige Kommunikation zwischen beiden herrschen. Der Autor des Designs muss auch bereit sein, Änderungen in sein Design aufzunehmen. Diese Art der Kommunikation und aktiven Arbeit mit dem SDD gewährleistet erst die erfolgreiche Dokumentation von Softwaresystemen, die langfristig wartbar sind.

Qualitätssicherung: Tester arbeiten eher passiv mit einem SDD. Ein SDD enthält für einen Tester die ersten Hinweise zum technischen Hintergrund dessen, was er testet. Für reine Blackbox-Tests eines grafischen User Interfaces mag dies nicht weiter relevant sein. Für die Erstellung von umfangreichen Systemtests, die eine Komponente und ihr Zusammenspiel mit anderen Komponenten eines Systems testen sollen, allerdings schon. So können in dem SDD unter anderem die Verbindungen und Abhängigkeiten zu anderen Systemen beschrieben sein, die bei der Testabdeckung und -erstellung auch mitbedacht werden können.

Requirements Engineer: Dem Requirements Engineer vermittelt das SDD einen erste...

Java Magazin
Wissen fürs Projekt oder für die Schublade?

Software-Design-Dokumente

Software Design Descriptions/Documents (SDD) [1] sind für die erfolgreiche Entwicklung und Wartung von Software unentbehrlich. Wirklich? Wer oder was beeinflusst deren Sinn und Einsatz im Projekt? Was ist eigentlich zu beachten, damit sie nicht schon während des Projekts zum Papiertiger werden und einen Nutzen darstellen können? Eine pragmatische Übersicht.

Berthold Schulte


Ein Dokument dient der schriftlichen Vermittlung von Information und Wissen zwischen Menschen. Software-Design-Dokumente beinhalten im Speziellen das Wissen über eine abstrakte Lösung zum Aufbau eines Stücks Software. Die darin dargestellte Information ist allerdings nur einer sehr kleinen Leserschaft zugänglich – da Wissen aus dem Bereich der Softwareentwicklung noch nicht zum Allgemeinwissen gehört, technisch komplex ist und eine eigene Sprache besitzt.

Die Zielgruppen

Wer gehört zu dieser Leserschaft, welche Erwartungen hat sie und welchen Einfluss hat sie auf das Dokument? Neben den Softwareentwicklern sind Tester, Requirement Engineers, Businessanalysten (BA) sowie der Kunde, die Projektleitung und die IT-Abteilung potenzielle Leser, wenn auch mit einem unterschiedlichen Fokus auf das, was sie aus dem Dokument erfahren wollen.

Softwareentwickler und Dev-Peers: Ein Softwareentwickler hat in der Regel die „engste“ Beziehung zu einem SDD. Einerseits erstellen Softwareentwickler das Design und die Dokumente oft selbst, andererseits arbeiten sie aktiv und ständig damit, da es ihre Arbeitsvorlage ist. Eben diese direkte Beteiligung an der Umsetzung verpflichtet den Entwickler auch zur Wahrung der Aktualität des SDDs. Hält er Änderungen am Design für nötig oder ergeben sich zwingend Gründe dafür, muss er sie in irgendeiner Form niederschreiben. Ansonsten gehen diese Änderungen in der Menge des Codes unter. Arbeitet er mit einem SDD eines zum Beispiel erfahreneren Entwicklers, so muss eine gute und ständige Kommunikation zwischen beiden herrschen. Der Autor des Designs muss auch bereit sein, Änderungen in sein Design aufzunehmen. Diese Art der Kommunikation und aktiven Arbeit mit dem SDD gewährleistet erst die erfolgreiche Dokumentation von Softwaresystemen, die langfristig wartbar sind.

Qualitätssicherung: Tester arbeiten eher passiv mit einem SDD. Ein SDD enthält für einen Tester die ersten Hinweise zum technischen Hintergrund dessen, was er testet. Für reine Blackbox-Tests eines grafischen User Interfaces mag dies nicht weiter relevant sein. Für die Erstellung von umfangreichen Systemtests, die eine Komponente und ihr Zusammenspiel mit anderen Komponenten eines Systems testen sollen, allerdings schon. So können in dem SDD unter anderem die Verbindungen und Abhängigkeiten zu anderen Systemen beschrieben sein, die bei der Testabdeckung und -erstellung auch mitbedacht werden können.

Requirements Engineer: Dem Requirements Engineer vermittelt das SDD einen erste...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang