Hi, ich stehe aktuell vor meinem ersten größeren Softwareprojekt und würde dieses gerne von Anfang an, möglich gut durchplanen um eine gute Softwarestruktur zu erhalten. Wie geht man dort am besten vor? Zunächst würde ich die Anforderungen definieren und diese anschließend in sinnvolle Module unterteilen, anschließend Interfaces definieren. Soweit, so gut. In welcher Art kann ich nun sinnvoll diese verschiedenen Module miteinander in Verbindung bringen, damit dritten (und auch mir) klar wird, in welcher Abhängigkeit die verschiedenen Module zueinander stehen. Am liebsten wäre mir ein Diagramm, das dies grafisch direkt visualisiert? Die gängigen Diagrammtypen von UML, finde ich da insgesamt nicht so passend. Gibt es da was passenderes? Wie plant ihr eine komplette Software? gruß Joe
Joachim schrieb: > würde > dieses gerne von Anfang an, möglich gut durchplanen um eine gute > Softwarestruktur zu erhalten. Tolle Idee. Nur teilt Dir der Kunde am Anfang höchstens 90% der Anforderungen mit. Dir letzten 10% schmeißen Deine Softwarearchitektur dann über den Haufen...
Joachim schrieb: > vor meinem ersten größeren Softwareprojekt und würde > dieses gerne von Anfang an, möglich gut durchplanen Ist für die meisten Projekte genauso effizient und sinnvoll wie es die 4 Jahrespläne im realen Sozialismus waren. Anforderungen ändern sich, man weiss am Anfang nie alle Parameter, also heist das Zauberwort flexibel bleiben und im Zweifel immer mal wieder refactoren.
Borislav B. schrieb: > Agile Entwicklung ist das zauberwort: SCRUM Das wiederum hat nichts mehr mit gesundem Menschverstand zu tun, sondern ist die Formalisierung des Entwicklungsprozesses. Quasi die FLiessbandarbeit für Softwareentwickler. Wie gut Fliessbandarbeit funktioniert zeigst sich in modernen Autoproduktionen, wo wieder zu Arbeitsgruppen zurückgegangen wurde. Aber natürlich ist es einfacher mit so einem formalisierten Arbeitsprozess eine ISO 900X Zertifizierung zu kriegen.
Der Optimist schrieb:
> Tolle Idee. Nur teilt Dir der Kunde am Anfang höchstens 90% der
Anforderungen mit. Dir letzten 10% schmeißen Deine Softwarearchitektur
dann über den Haufen...
90% .. ist viel zu optimistisch. es werden im besseren Fall 10% der
Anforderungen bekannt sein, eher weniger.
:
Bearbeitet durch User
Oh D. schrieb: > 90% .. ist viel zu optimistisch. es werden im besseren Fall 10% der > Anforderungen bekannt sein, eher weniger. Es ist eigentlich sogar noch schlimmer: etliche der Anforderungen, die der Kunde einem mitteilt, sind entweder gar keine Anforderungen oder der wenig durchdachte Versuch, Implementierungsdetails durchzudrücken. Oder die Anforderungen sind so allgemein gehalten, dass die Implementierung aufwändiger als unbedingt nötig wird. Beispiele: Versorgungsspanung 1V bis 100V, Temperaturbereich -1°C bis 72°C. Ich hatte gerade erst neulich einen Kunden, der darauf bestand, dass die von ihm spezifizierten Ströme eines Schaltmoduls wirklich als Dauerströme aufzufassen sind und nicht nur als kurzzeitige Einschaltströme. Jetzt hat der Kunde eben eine gigantisch teures Modul, welches sich auch kaum noch fertigen und warten lässt. Und für die zugehörige Prüfvorrichtung benötigt er nun einen 32A-Drehstromanschluss. Mittlerweile hat der Kunde aber eingesehen, was er da bestellt und geliefert bekommen hat. Das Nachfolgeprodukt ist nun deutlich zurückhaltender spezifiziert. ;-)
Joachim schrieb: > Hi, > > ich stehe aktuell vor meinem ersten größeren Softwareprojekt und würde > dieses gerne von Anfang an, möglich gut durchplanen um eine gute > Softwarestruktur zu erhalten. Wie geht man dort am besten vor? > Zunächst würde ich die Anforderungen definieren An dieser Stelle geht in der Regel das Meiste schief. Bzw. ein Softwareprojekt wird um so teurer, je später man Fehler entdeckt, die in dieser Anfangsphase gemacht wurden. Wie andere schon gesagt haben: Es kann ein echtes Problem sein, wenn der Kunde immer wieder mit neuen Anforderungen ankommt. Man muss hier einen vernünftigen Weg finden sich miteinander abzusprechen. Auf jeden Fall sollte man in einem Lastenheft mit dem Kunden zusammen schriftlich festhalten, was umzusetzen ist. Dieses Dokument wird von beiden Seiten reviewt und unterschrieben. Dem Kunden muss klar sein: Was nicht schriftlich miteinander vereinbart wurde, wird auch nicht umgesetzt. Und wenn dann nachträglich neue Anforderungen hinzukommen, dann verursacht dies eben zusätzliche Kosten. Leider verspricht der Vertrieb dem Kunden gerne mal das Blaue vom Himmel, und die Entwicklung muss es dann ausbaden. :-( > und diese anschließend in sinnvolle Module unterteilen, anschließend > Interfaces definieren. > Soweit, so gut. In welcher Art kann ich nun sinnvoll diese verschiedenen > Module miteinander in Verbindung bringen, damit dritten (und auch mir) > klar wird, in welcher Abhängigkeit die verschiedenen Module zueinander > stehen. Du zäumst da irgendwie das Pferd von hinten auf? Du legst ja selbst die Anzahl und den Umfang der Module fest. Also legst Du auch die Abhängigkeiten zwischen den Modulen fest. > Am liebsten wäre mir ein Diagramm, das dies grafisch direkt > visualisiert? Die gängigen Diagrammtypen von UML, finde ich da insgesamt > nicht so passend. Gibt es da was passenderes? Auf oberster Ebene kann eine Art Blockschaltbild hilfreich sein, um die grundsätzlichen Beteiligten und den grundsätzlichen Informationsfluss aufzuzeigen. Wenn man es noch genauer haben will, kann man Aufrufgraphen erstellen: Welche Funktion ruft welche andere auf. Sowas wird freilich gerne im Nachhinein anhand des Codes erstellt, zum Beispiel mittels des Tools Doxygen und entsprechender Kommentare im Sourcecode. > Wie plant ihr eine komplette Software? Indem man Leute fragt, die davon Ahnung haben. Und die im richtigen Leben schon erlebt haben, was in einem realen Projekt so alles schiefgehen kann.
Oh D. schrieb: > Der Optimist schrieb: > >> Tolle Idee. Nur teilt Dir der Kunde am Anfang höchstens 90% der > Anforderungen mit. Dir letzten 10% schmeißen Deine Softwarearchitektur > dann über den Haufen... > > 90% .. ist viel zu optimistisch. es werden im besseren Fall 10% der > Anforderungen bekannt sein, eher weniger. Dann, mit Verlaub, sind die Leute vollkommen unfähig die für den direkten Kontakt mit dem Kunden zuständig sind. Weil sie zum Beispiel nicht die richtigen Fragen stellen und nicht für den Kunden mitdenken.
Andreas S. schrieb: > Mittlerweile hat der Kunde aber eingesehen, was er da bestellt und > geliefert bekommen hat. Das Nachfolgeprodukt ist nun deutlich > zurückhaltender spezifiziert. ;-) Wenn er seinen Fehler selbst einsieht ist das ja noch gut. Oft genug bist dann du der Buhmann, weil sich der Verantwortliche beim Kunden auf die Kosten des Zulieferers rausredet. Dann bist du für den Folgeauftrag raus obwohl du nichts falsch gemacht hast.
Andreas S. schrieb: > Ich hatte gerade erst neulich einen Kunden, der darauf bestand, dass die > von ihm spezifizierten Ströme eines Schaltmoduls wirklich als > Dauerströme aufzufassen sind und nicht nur als kurzzeitige > Einschaltströme. Jetzt hat der Kunde eben eine gigantisch teures Modul, > welches sich auch kaum noch fertigen und warten lässt. Und für die > zugehörige Prüfvorrichtung benötigt er nun einen 32A-Drehstromanschluss. > > Mittlerweile hat der Kunde aber eingesehen, was er da bestellt und > geliefert bekommen hat. Das Nachfolgeprodukt ist nun deutlich > zurückhaltender spezifiziert. ;-) Man kann seine Kunde auch erziehen - wenn diese nicht völlig doof sind. Spätestens beim Thema Geld kriegt man die Leute doch recht gut :-) "Sie wollen das so haben? Klar, kann man machen. Aber dann wird es sehr teuer. Ich schlage Ihnen alternativ Lösung X vor, mit der sie deutlich günstiger fahren."
Mark B. schrieb: > Dann, mit Verlaub, sind die Leute vollkommen unfähig die für den > direkten Kontakt mit dem Kunden zuständig sind. Weil sie zum Beispiel > nicht die richtigen Fragen stellen und nicht für den Kunden mitdenken. Das ist aber ein Wechselspiel. Ich habe schon alles erlebt von einem völlig unrealistischen Anforderungskatalog über 170 Seiten für ein Projekt das max. 30-50k Euro Umsatz bringen sollte und eigentlich ein "Standardprodukt" unserer Firma war, das ohne Änderungen nur beim Kunden konfiguriert werden sollte bis hin zu Kunden die gesagt haben: "Programmiert mal was und zeigt es uns, wir sagen euch dann was wir anders wollen" Ernsthaft! Das 170 Seiten Anforderungspamphlet kam übrigens von einem großen internationalen Beratungsunternehmen. Der "high Potential" der es verfasst hatte hatte zuvor wahrscheinlich noch nie was mit dem Thema zu tun, aber die Beratungsfirma hat (geschätzt) doppelt so viel für das Pamphlet erhalten wie sie uns für die Software zahlen wollte.
Joachim schrieb: > ich stehe aktuell vor meinem ersten größeren Softwareprojekt und würde > dieses gerne von Anfang an, möglich gut durchplanen um eine gute > Softwarestruktur zu erhalten. Beruflich oder privat? > In welcher Art kann ich nun sinnvoll diese verschiedenen > Module miteinander in Verbindung bringen, damit dritten (und auch mir) > klar wird, in welcher Abhängigkeit die verschiedenen Module zueinander > stehen. Am liebsten wäre mir ein Diagramm, das dies grafisch direkt > visualisiert? UML Komponentendiagramm für die Struktur, Aktivitäten- oder State-Maschine-diagramm, oder Message-Sequence-Charts für das Verhalten. > Die gängigen Diagrammtypen von UML, finde ich da insgesamt > nicht so passend. Was passt (dir) dann nicht? > Gibt es da was passenderes? Wie plant ihr eine > komplette Software? In Entwicklungs-schritten oder Releases. Das ist aber ein anderes Brot als SW-Architektur/Design und UML.
So als Anregung, nebst dem SCRUM/UML-Modekram mal ganz pragmatisch: - In Python einen Rohgerüst-Prototypen (Module für einzelne trennbare "Units") machen - Gleich von Anfang an daraus sinnvolle (!) Dokumentation erzeugen, wie mit genanntem Doxygen und den grafischen Co-Tools. - Von Anfang an Richtung stabile Bibliothek arbeiten: Unit tests für SW schreiben (Paradeanwendung für Python) - Später Performance-Probleme mit Redesign einzelner Module in sauberer Compilersprache ausmerzen Manche schreiben auch gleich ihr ganzes Framework in Java...warum nicht. In der Kommunikation mit dem Kunden hat sich ein früh ausgelieferter Simulator auch schon mal ausgezahlt: Damit lassen sich schon früh die Features festnageln: "Das kriegste". Und bloss sich nicht in OO verzetteln. Das hat schon so manches grosse SW-Projekt aus den Angeln gehoben...
Joachim schrieb: > Zunächst > würde ich die Anforderungen definieren und diese anschließend in > sinnvolle Module unterteilen, anschließend Interfaces definieren. Genau so ist es richtig. Lass Dich nicht von den Amateuren hier beirren. Ordne die unterschiedlichen Anforderungen und Funktionen den unterschiedlichen Modulen zu und überlege, was die Grenzen der Module sind, und welches Modul mit welchem redet. Die Abgrenzungen sind sehr wichtig für eine belastbare Struktur. Die Module ordnet man horizontal und vertikal, wie es so schön heißt. Du hast Schichten, in denen Module "gleicher Art" nebeneinander liegen und voneinander unabhängig sind. Die einzelnen Schichten kommunizieren jeweils nur nach oben oder unten, und zwar nur mit der direkten Schicht drüber oder drunter. Nie durch die Schichten "durch". Weiter oben sind die abstrakten Schichten, ganz unten die Basics z.B. Datenstrukturen wie Sets, Maps etc. Darüber dann z.B. Service-Module wie Konfig-Dateien lesen und schreiben, Datenbank-Treiber etc. Darüber dann schon eine "Business-Schicht", die also bestimmte Abläufe der Software moduliert. Ganz oben die Bedien-Oberfläche etc. Wie Du das zeichnest? Papier und Bleistift, später dann auch farbige Filzstifte. Ist immer noch das Beste!
Software-Entwickler schrieb: > Genau so ist es richtig. Lass Dich nicht von den Amateuren hier beirren. > > Ordne die unterschiedlichen Anforderungen und Funktionen den > unterschiedlichen Modulen zu Wenn ich ein A einem B zuordne, dann bedeutet das für mich dass B zuerst existiert. Denn etwas nicht Existentem kann man nichts zuordnen. Wie passt das damit zusammen, dass zuerst natürlich die Anforderung existiert und danach das Softwaredesign erstellt wird?
Ich bin grad an einer Prozess Mess- & Controlsoftware. Der grosse Aufwand ist das GUI, wahrscheinlich 95% des Aufwandes wird GUI sein. Ich beginne nun mit den Visualisierungen, Menues, Datenhandling. Alles Tests, um zu schauen, wie man das Interface am Intuitivsten rueberbringen soll. Die paar Sensoerchen und Aktoerchen kommen dann in der letzten Woche.
Joachim schrieb: > würde dieses gerne von Anfang an, möglich gut durchplanen um eine gute > Softwarestruktur zu erhalten. Eine gute Struktur erhältst Du nur mit Erfahrung und Verständnis der Aufgabe. Entweder hast Du schonmal was ähnliches gemacht, oder du mußt bei der Entwicklung probieren, refaktorieren, wegschmeißen, umbauen... > Zunächst > würde ich die Anforderungen definieren Hä? Du? Definieren? Was meinst Du damit?
>> Zunächst >> würde ich die Anforderungen definieren > >Hä? Du? Definieren? Was meinst Du damit? Die ueblichen Traeumer eben. Die Anforderungen sind, dass der Kunde, resp der Abnehmer zufrieden ist, was auch immer das bedeutet, auch wenn die Wuensche dauernd aendern. Was auch immer du planst auch mit Pflichtenheft und Unterschrift ist ja schoen, fliegt aber in die Tonne, wenn der Abnehmer sich das Ergebnis total anders vorgestellt hat und das Resultat daher als voellig unbrauchbar bezeichnet. Deswegen sollte man am Anfang und auch zwischendurch einfach mit dem Abnehmer etwas rumspielen, um zu sehen, ob man noch auf der rechten spur ist.
:
Bearbeitet durch User
Oh D. schrieb: > Was auch immer du planst auch mit Pflichtenheft und Unterschrift ist ja > schoen, fliegt aber in die Tonne, wenn der Abnehmer sich das Ergebnis > total anders vorgestellt Es fliegt keineswegs in die Tonne, sondern wenn geliefert wurde, was bestellt wurde, dann muß der Kunde auch bezahlen. Notfalls wird er eben gerichtlich gezwungen. Leistung verballern und dann nicht zahlen wollen ist halt nicht drin - und Kunden, die nicht zahlen, kann man auch eben deswegen hart behandeln. Alleine dafür braucht man schon ein unterschriebenes Pflichtenheft, denn es gibt Kunden, die mittendrin auf einmal "wünsch Dir was" spielen, das aber nicht bezahlen wollen. Außerdem ist es bei einem ausgeschrieben Auftrag oftmals Praxis, den Preis so zu kalkulieren, daß er zwar unwirtschaftlich ist, man aber damit die Ausschreibung kriegt. Wenn der Kunde erstmal vertraglich gebunden ist, stößt man sich über die Änderungen gesund - denn ab dem Punkt kann der Kunde nicht mehr zurück, ohne daß das alles für ihn noch teurer wird. Also eine Art "late vendor lock-in". Geht besonders bei staatlichen Auftraggebern. Eine andere Vorgehensweise, die für beide Seiten fairer ist, wäre, den Vertrag zu splitten, und zwar in eine Demophase und eine optionale Produktphase. In der Demophase wird mit rapid prototyping irgendwas zurechtgedengelt, egal wie, was die Funktionen halbwegs vortäuscht. Wenn dem Kunden dabei auffällt, nee so doch nicht, ist das kein Problem, es darf beliebig verpfuscht werden. Visual Basic und andere Tools gehen hier hervorragend - egal wie lahm es läuft, Hauptsache schnell irgendwas zurechtklatschen. Die Demophase berechnet man nach Zeit. Obendrein merken beide Seiten, ob man mit dem anderen gut zusammenarbeiten kann oder nicht. Hat man das fertig, dann ist klar, was der Kunde will, und danach kann man das eigentliche Angebot erstellen. Solange die Demophase kurz ist im Verhältnis zur gesamten Projektdauer, kommt das den Kunden nichtmal teurer, weil jede Menge Doppelarbeit durch späte Änderungen ja entfällt. Davon ab ist es tatsächlich wichtig, wie hier auch schon gesagt wurde: mit dem Kunden reden. Und damit meine ich keine Schlipsträger, sondern direkt auf technischer Ebene. WAS will der Kunde, WAS ist sein Problem? Was für Normen und Standards müssen beachtet werden? Erst wenn man das WAS genau begriffen hat, ergeben Gedanken über das WIE überhaupt Sinn. Der Fehler wird oft gemacht, zu früh loszulaufen - was am Ende länger dauert. Auch wichtig: frühzeitig mit dem Kunden nicht nur über den Lieferumfang nachdenken, sondern auch zu gucken, welche späteren Erweiterungen gewollt oder sinnvoll sind. Das erspart einem dann oftmals heftige und teure Designänderungen. Die späteren Features müssen zunächst nicht implementiert werden, aber die Architektur muß sie erlauben. Man kann andererseits nicht alle denkbaren Änderungen auf Verdacht in die Architektur nehmen, weil man dann ein aufgeblähtes System unter bekommt, Stichwort YAGNI.
Nop schrieb: > Es fliegt keineswegs in die Tonne, sondern wenn geliefert wurde, was > bestellt wurde, dann muß der Kunde auch bezahlen. Notfalls wird er eben > gerichtlich gezwungen. Es spricht sich sehr schnell rum, wenn ein Lieferant so vorgeht und sich nicht flexibel zeigt. Dann hat man plötzlich keine Kunden mehr. Natürlich gibt es Ausnahmen. SAP und SAP-Berater können sich offensichtlich alles erlauben. Auf der anderen Seite, als Abnehmer macht besonders der Staat alles mit. Der wird gepflegt mit V-Modell ausgeplündert.
Jack schrieb: > Es spricht sich sehr schnell rum, wenn ein Lieferant so vorgeht und sich > nicht flexibel zeigt. Dann hat man plötzlich keine Kunden mehr. Ja und? Wenn man Kunden, die nicht wissen, was sie wollen, kostenlos teure Dienstleistungen verkauft, dann geht man sehr schnell PLEITE. Außerdem spricht es nicht gegen einen Lieferanten, wenn er für vertragsgemäße Leistung auch vertragsgemäß bezahlt werden will. Arbeitest Du eigentlich kostenlos, falls Dein Arbeitgeber aufgrund mangelhafter Zielvereinbarungen im nachhinein unzufrieden ist?
Oh D. schrieb: > Was auch immer du planst auch mit Pflichtenheft und Unterschrift ist ja > schoen, fliegt aber in die Tonne, wenn der Abnehmer sich das Ergebnis > total anders vorgestellt hat und das Resultat daher als voellig > unbrauchbar bezeichnet. Das Problem bei solchen in Stein gemeißelten Spezifikationen (Lastenheft, Pflichtenheft, usw.) besteht darin, dass ggf. völlig an den tatsächlichen Anforderungen vorbeientwickelt wird und alle Beteiligten dies auch wissen. Wenn irgendwelche sinnvollen Änderungswünsche, von denen alle profizieren würden, auf diese Art und Weise ausgeschlossen werden bzw. für denjenigen, der solch einen offensichtlichen Wunsch unterbreitet, mit einem zu hohen Kostenrisiko verbunden wären, kommt es ggf. sogar zu einem Stillstand des Projektes. Ganz konkret kenne ich ein sehr großes und langwieriges Projekt, in dessen vor langer Zeit ausgehandeltem Vertrag festgelegt wurde, dass die Entwicklungsumgebung und später auch ein Teil der auszuliefernden Software ausschließlich für Windows XP entwickelt werden sollten. Das war zum Zeitpunkt der Vertragsverhandlungen als zukunftsweisende Formulierung zu verstehen, in dem Sinne, dass Altlasten unter Windows 2000 oder 98 ausgeschlossen werden sollten. Auf Grund der langjährigen Verhandlungen und auch sehr langen eigentlichen Projektlaufzeit ergab sich dann aber das Problem, dass Windows XP schon längst abgekündigt war und eigentlich auch auf keinen Entwicklerarbeitsplätzen mehr verwendet werden sollte. Daher gab es inoffizielle Versionen der Entwicklungsumgebung, die auch unter Windows 7/8 liefen. Nur bei Lieferungen an den Kunden musste peinlich genau darauf geachtet werden, dass die Software ausschließlich unter XP lief. Alles andere hätte einen Vertragsbruch bedeutet. Und NEIN, man hätte das ganze nicht auf der technischen Ebene klären können, sondern Spezifikationsänderungen waren immer mit gigantischem Aufwand und (unternehmens-)politischen Verhandlungen auf etlichen Ebenen verbunden. Auf Lieferantenseite verlies man sich auch darauf, sich irgendwann die unter neueren Betriebssystemen lauffähigen Versionen durch den Auftraggeber vergolden lassen bzw. mit anderen Ansprüchen verrechnen zu können. Wenn es sich bei dem Projekt um eine Produktentwicklung für den freien Markt gehandelt hätte, wären alle Beteiligten damit gewaltig auf die Nase gefallen.
:
Bearbeitet durch User
Das ist die Aufgabe eines Spezialisten, dem KUNDEN zu sagen was er haben will!! Andere Unternehmer werden scheitern! Du hörst Dir seinen Wunsch an und musst verstehen was er will, was technisch geht aufwendig ist und machbar kann er nicht überblicken.. Sobald DU dir ein Bild gemacht hast, sagst DU ihm wie es aussieht und er wird Wünsche einbringen, diese musst DU!! einbinden. Jemand der das alles nicht kann ist vielelicht ein toller Programmierer aber ist halt kein Unternehmer..ein häufiges Problem. Aber das kann man lernen..learning by doing. Man muss nur bereit dazu sein
Vermutlich ist Joachim Programmierer, Kunde, Marketingchef, und alles andere in Personalunion. Das klingt nach einem Privatprojekt. Also kann er mit sich selber alles in Ruhe ausdiskutieren, so lange er will. Oliver
Oliver S. schrieb: > Vermutlich ist Joachim Programmierer, Kunde, Marketingchef, und alles > andere in Personalunion. Das klingt nach einem Privatprojekt. Anders ist es nicht zu erklären, dass er die Anforderungen definieren will. Bei einem Kundenprojekt kommt das Was und Warum vom Kunden und steht (optimal) im Lastenheft. Oder wird erklärt, an Beispielen gezeigt, gemalt, geklatsch, getanzt, ...). Der "Programmierer" kann die Anforderungen ahnen, analysieren, verstehen, umsetzen, aufnehmen, respektieren, erfüllen, ignorieren, ... aber nicht erstellen. Der Programmierer bestimmt das Wie und Womit (in Pflichtenheften, rototypen, Simulationen, ...). Anforderungen sind die Basis einer Entwicklung. Anforderungen sind ihrerseits aber auch immer das Ergebnis einer Entwicklung, eines Kreativen Prozesses. Am Anfang der ersten Entwicklung stehen "Ideen". Z.B. eine stupide Arbeit vom Computer machen zu lassen oder eine bekannte Software ein bisschen besser zu machen. Beispiel: Ein Kunden-DAU möchte Software X um y Features erweitern. Er als DAU kann die Anforderungen aber nicht formulieren, also tue *ich* es. Genau das passiert leider viel zu oft (in schönen Vorlagen gemäß der Firmenprozesse) und ist ein teueres Missverständnis!
@TO: Ist im Grunde gar nicht so kompliziert. Im Grunde sammelt eine
Anforderungsanalyse nur eine Menge von Anforderungen und
Einschränkungen, auf deren Grundlage später ein Design (->Software
Design) und noch später eine Implementierung abgeleitet werden kann.
Zuerst solltest du erfassen, welche Rollen es in deinem Projekt gibt. So
könnte es z.B. Servicetechniker/Entwickler, Benutzer oder Gast geben.
Auf der Grundlage hin kannste mit einfachen, unverschachtelten Sätzen
formulieren wie z.B. "Als Servicetechniker möchte ich Daten loggen
können" oder "Als Kunde möchte ich, dass die Rolladen bei
Sonnenuntergang geschlossen werden". Ob es die Rollen dann wirklich
gibt, oder ob du selber diese dann ausfüllen wirst, ist erstmal
zweitens. Du musst dir nur die jeweilige Brille für das Formulieren der
Anforderungen aufsetzen.
Anforderungen werden nochmal kategorisiert in 'funktional' und
'nichtfunktional' - das solltest du so berücksichtigen, weil das für
Priorisierungen bzw. Projektumfang eine Rolle spielen kann. Funktional,
sagt der Name schon, das ist das, was mindestens drinne sein muss, damit
das jemand einsetzen kann (halt Funktionalität). Nichtfunktionale
Anforderungen (oder auch Qualitäten) sind eher weiche Kriterien, z.B.
'Performance' (Software muss 10fps rendern können), aber auch
'Wartbarkeit' oder 'Portierbarkeit'. Nicht vom Namen täuschen lassen,
die Dinger sind genauso wichtig wie die Funktionalität, aber nicht für
den Kunden, sondern für den Entwickler.
Genauso wichtig wie Anforderungen, sind Einschränkungen, denn erst die
machen deine gesammelten Kundenwunsch-Sprechblasen zu etwas zeitlich
Umsetzbaren - also zu einem Projekt. Da gehören alle Sachen rein, die
später im Verlauf des Softwareprojekts unveränderbar sind und bleiben,
das kann z.B. die Hardwareplattform sein. Aber auch Sachen, die dir das
Leben erleichtern - z.B. Reaktionszeiten ('Die Software muss höchstens
einmal pro Minute 'xy' auslösen.').
Hast du dir daraus sorgfältig eine schöne Liste erstellt, welche
Funktionalitäten, Qualitäten und Einschränkungen deine Software bieten
soll, schreibst du über diese Liste drüber 'Software Requirements
Specification' (SRS). Die lässte dir vom Kunden abnicken, soweit
möglich, denn auf deren Grundlage findet dann das Design statt bzw.
darauf baut das komplette Design/die Software-Architektur auf. Und erst
dann beginnt der nächste Schritt, nämlich die Softwareverteilung zu
definieren, z.B. auf welchem Rechner läuft welcher Server, aus welchen
Komponenten (z.B. DLLs) setzt sich die Software zusammen.
Das mal kurz im Überblick. Tatsächlich gehören noch eine ganze Menge
Dinge mehr dazu: Softwarekonfigurationsverwaltung,
Softwareprojektverwaltung, Softwaretests (z.B. Unittests) und eben auch
die Implementierung. Muss aber auch so sein, wenn deine Software kein
bewegliches Ziel werden soll. Und das geht sauschnell, wie dir jeder
Softwareentwickler bestätigen kann.
Mark B. schrieb: > Wo ist eigentlich der Themenersteller abgeblieben? Der versucht momentan eine SW Architektur in M$ Projekt zu planen.
Eric B. schrieb: > Der versucht momentan eine SW Architektur in M$ Projekt zu planen. Das habe ich bei Firmen, die embedded-Produkte selber entwickeln, schon häufiger gesehen. Ein paar Junge grüne Leute kämpfen voller Elan gegen Compiler, Anforderungen, Aufgabenstellung, Hardware und was weiss ich was. Neue Ideen werden direkt umgesetzt, Vergessenes nachgeflickt, für den Auslieferdruck getrickst und Dokumentation auf St.Nimmerlein verschoben. Der Code sieht bei allen Chaotisch aus, trotzdem haben einige Struktur, andere sind Read-Only. Einige erleben Schiffbruch, aber einige haben Erfolg und der gibt ihnen nun die Möglichkeit, es künftig "richtig" zu machen. Und ab da ist dann Ende mit jeder Innovation, außer bei den Querulanten.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.