July 25, 2017     Login   Register  
 
 
 
Home
 
Silverlight
 
Methodik
 
Für Entwickler
 
Referenzen
 
Über uns
 
 
 
 
 
 
Use Case Analyse
 
Agile Prozesse?
 
Datenbank-Modellierung
 
 
 
 
 
 MethodikUse Case Analyse   
Use Case Analyse - Grundstruktur der Projektübersicht Minimize

Aufnahme der Anforderungen in Use Cases

Die listenartige Aufnahme von Anforderungen ( „Lastenheft“) spiegelt in keiner Weise unsere heutige (objektorientierte und immer mehr servicebasierte) Programmier-Realität wieder – ein Grund, warum nach wie vor viele Softwareentwicklungs-Projekte schief gehen, und zeitlich oder finanziell aus dem Ruder laufen.

Die UseCase-Analyse ist eine Methode zur Aufnahme der Anforderungen für ein Software-Projekt, bei dem diese Anforderungen aufgegliedert werden in sogenannte Use Cases, d.h. Anwendungsfälle, die sich definieren als kleinste unabhängige Funktionseinheiten. Dabei bedeutet „unabhängig“, daß sie auch an anderer Stelle und mit Beziehung zu anderen UseCases wieder verwendet werden können. Dieses Use Cases werden zueinander in Beziehung gesetzt und so schematisch in Use Case Diagrammen dargestellt.

Ein einfaches Beispiel für solche Beziehungen: „Wir müssen in der Zentrale am Desktop Aufträge erfassen, es werden aber auch Aufträge im Web erfaßt; beide haben vieles gemein, aber auch ihre Besonderheiten“: heißt hier ein Parent-UseCase („Aufträge erfassen“) mit einer speziellen Art von Beziehung („Generalisierung“) zu zwei Child-UseCases („Auftrag erfassen online“ und „Auftrag erfassen office“). Also muß der zentrale UC nur einmal beschrieben werden und in den beiden weiteren nur die jeweilige Abweichungen. Entwickler hören hier schon dabei schon heraus „Parent-Child-Klassenbeziehung“ (Generalisierung), die sich entsprechend in der Programmierung dann niederschlägt und in Folge dessen auch in der Struktur der Aufwände. Simples Use Case Diagramm

Modellierung von Realisierungs-Zyklen

Das Ziel der UseCase-Analyse ist dabei, von vornherein ein möglichst komplettes Bild von der zukünftigen Anwendung zu erhalten, auch wenn bestimmte Teile davon erst nur vorgesehen und grob beschrieben, aber vorerst nicht genauer detailliert oder gar umgesetzt werden – ähnlich wie ein Haus, von dem nur ein erstes Stockwerk ausgebaut ist, dessen Fundament aber auch das künftig auszubauende Dachgeschoß tragen muß.

Wir ordnen jeden Use Cases einer Entwicklungsetappen (bzw Iteration) und damit einem Release-Zyklus zu. So ist es möglich, die Beauftragung einer Software auf den mindesten Grundstock zu reduzieren, ohne deshalb auf das gute Vorausdenken künftiger Anforderungen zu verzichten und Wege zu verbauen. (Rechts und unten sehen Sie die farbliche Kennzeichnung von Use Cases je nach Zuordnung zu Iterationen - in Übersicht und Use Case Diagramm). Simples Use Case Diagramm

Unified Modelling Language - die Arbeit mit Standards

UC-Diagramm Use Case Analyse ist eine standardisierte Notationssprache – ähnlich wie Architekten ihre standardisierte Darstellung (von Türen, Wänden, Erde…) kennen; diese wurde in der „Unified Modelling Language“ von einigen Experten festgelegt und seit dem weiterentwickelt. So können diese Use Case Darstellungen ebenso von „fremden“ Entwicklern gelesen werden, um sofort zu erfassen, wie die Struktur der Anwendung im Blick auf ihre Anforderungen aussieht.

Unterschiedliche Verständnisse (z.B. in verschiedenen Fachabteilungen einer Firma, die die künftige Software in Auftrag gibt) werden anhand der durch solche Analyse gemeinsam erstellten oder geprüften Use Case Diagrammen schnell offenbar, so daß nach meiner Erfahrung häufig an einzelne Use Cases eine Reihe von Fragen geheftet werden müssen, die hausintern gekärt werden müssen – wie gut, wenn dies nicht erst geschieht, nachdem die unzufriedenen Anwender eines Programmes feststellen, daß es gar nicht macht, was sie sich eigentlich vorgestellt haben!

Sorgfältige Aufnahme der UC erspart folglich eine Menge späterer Unzufriedenheit und Irrwege, unnötige Ausgaben und Zeitverlust. Die Anwender sind bereits in der Software zuhause, noch bevor sie geschrieben ist, weil sie am ganzen Analyseprozess gründlich beteiligt waren – so kann die Einführung der Software weit reibungsloser und schneller von statten gehen.
  
 
 Copyright 2010 by Business & System   Terms Of Use  Privacy Statement