Diskussion:Prozessmodell (Software)

Hallo,

verantworte gerade CMMI Zertifizierung und beschäftige mich mit diesen Themen schon geraume Zeit.

Modelle gibt es in Firmen heute verschiedene,top down ein Geschäftsmodell, ein Geschäftsprozessmodell, ein Orgmodell usw. und irgendwann mal in der Softwareentwicklung auch ein Datenmodell.

Ein Geschäftsrozessmodell beschreibt grundsätzlich die Kernprozesse und Stützprozesse in einer Firma, nach deren Sie "funktioniert".

Ein Softwareentwicklungsprozess beschreibt widerum wie in der Firma Software entwickelt wird, nach welchen Abfolgen, nach welchen Rollen und Regelwerken. Getrennt zu betrachten sind Softwareentwicklungsmethodiken (Wasser, V, RUP, Iterative usw. die das methodische Vorgehen in der "Entwicklung selbst beschreiben" und unterstützt werden durch Stützprozesse wie Riskmgt, CR-Mgt., Lieferantenmgt. usw..

Das heißt man sollte den Softwareentwicklungsprozess generisch halten und nach Wahl der Methode in die Details verzweigen. Genannte Stützprozess sollte man geclustert dazu getrennt behandeln wegen der Übersichtlichkeit.

Entwickelt man Produkte und dies immer nach dem gleichen Vorgehen kann man dies ntürlich auch in einem Prozess beschreiben.

CMMI wiederum ist eine Methodik/Leitfaden zur Überprüfung der Qualität des Softwareentwicklungsprozesse über den man int. anerkannt die Qualität seiner Vorgehensweisen ... zertifizieren lassen kann, d. h. hier wird beleuchtet was habe ich mir vorgegeben und wie lebe ich es in der Praxis. Den SW Entwicklungs-Prozess selbst und die eingesetzte(n) Methodik(en) aber wählt besser beschreibt man selbst oder setzt auf Standards auf.

Themen die im Rahmen eines SW-Entwicklungsprozessdesigns, auch bei CMMI berücksichtigt werden müssen sind:

Requirementmanagement Projektmanagement Riskmanagement Lieferantenmanagement Contractmanagement Änderungsmanagement Claimmanagement Prozessmanagement Testmanagement Qualitymanagement Abnahmemanagement Fehlermanagement das ganze Themengebiet manage and control über alle Gebiete hinweg bei SW-Entwicklung entlang von Produkten das Thema Marktanlayse, Beobachtung (es nützt nichts ein Produkt am Markt vorbei zu entwickeln) das Thema Statistiks und verdichtetes Mgt. Reporting

---

Mir ist nicht klar, was ein Prozessmodell eigentlich sein soll.

Sicher muss man CMM/CMMI, Spice und ISO 12207 ISO/IEC 12207 irgendwie von Vorgehensmodellen wie dem V-Modell oder Extreme Programming unterscheiden. -- 212.144.179.77 22:40, 14. Mai 2005 (CEST)

Der Begriff ist hier als Synonym zum "Vorgehensmodell" verwendet, i. allg. ist aber ein "Prozessmodell" das Gegenstück zum Datenmodell, nämlich eine fachorientierte Beschreibung von "Geschäftsprozessen"! --Cami de Son Duc 19:51, 30. Jun 2005 (CEST)

Abschnitt "Keine Erfolgsgarantie"

Dieser Abschnitt gefällt mir überhaupt nicht! Er gibt meiner Meinung nach lediglich Meinungen und Binsenweisheiten wider. Natürlich gibt ein Prozessmodell keine Garantie für ein Gelingen. Das behauptet ja auch keiner. Die "Wikipedia" sagt hierzu beispielsweise: "Um den Entwicklungsvorgang übersichtlicher zu gestalten und beherrschbar zu machen, bedient man sich so genannter Vorgehensmodelle", wobei man "beherrschbar" evtl. durch "beherrschbarer" ersetzen sollte ... Dem "Managementvoodo" kann man ohne Probleme den "Entwickeln-ist-Kunst"-Aberglaube gegenüberstellen. Ein Absatz wie das hier vorliegende "Nicht unerwähnt ..." müßte eigentlich in jeden Wikipedia-Artikel eingefügt werden, wo kommerzielle Produkte genannt werden (wobei diese hier noch nicht einmal im Mittelpunkt stehen). Außerdem sollte man auch nicht unerwähnt lassen, dass Entwickler das nicht an Regeln gebundene Programmieren ebenso verherrlichen.

Der "Warnungs"-Abschnitt läßt den den Eindruck entstehen bzw. soll offensichtlich den Eindruck entstehen lassen, dass die Anwendung von Vorgehensmodellen geradewegs in den Ruin führt. Ehrlich gesagt: Das glaube ich nicht. Beispiel FISCUS: Der im entsprechenden Wikipedia-Artikel genannte Link http://www.bundesrechnungshof.de/ergebnis2002/bem66.html führt zu einem Artikel, wo folgende Schlußfolgerung des Bundesrechnungshofes zu lesen ist: "Die lange Projektdauer, die Vielzahl an zu beteiligenden Gremien, die Zeitverzögerungen im Projektverlauf, die nicht ausreichende Personalunterstützung durch die Länder und das sich abzeichnende deutliche Überschreiten des ursprünglichen Kostenrahmens deuteten nach den Prüfungserfahrungen des Bundesrechnungshofes auf ein hohes Abbruchrisiko des IT-Projekts FISCUS hin." und "Der Bundesrechnungshof hatte das Bundesministerium der Finanzen (BMF) bereits im Jahre 1997 darauf hingewiesen, dass die Konzentration der Entscheidungsstrukturen auf wenige Entscheidungsträger die Voraussetzung eines wirksamen und wirtschaftlichen Projektmanagements ist." Dies sind keine in der Verwendung eines Vorgehensmodells begründeten Mißstände, oder? Das ist mangelndes Risiko- bzw. schlechtes Projektmanagement. Und wer weiß, wie die genannten Projekte ohne jegliches Vorgehensmodell abgelaufen wären (bzw. sind sie vielleicht deshalb gescheitert, weil Vorgehensmodelle nur vordergründig angewendet wurden?).

Kurz und gut: Wenn niemand Einspruch einlegt, werde ich diesen Absatz ersatzlos streichen. Die Negativbeispiele Nivadis und Gesundheitskarte habe ich jetzt schon einmal entfernt, da mir auch nach Lesen der entsprechenden Wikipedia-Artikeln nicht klar wird, warum sie hier aufgeführt sind. Siggisiggi 20:09, 9. Nov 2005 (CET)

Abschnitt "Keine Erfolgsgarantie" soll stehen bleiben

Ich denke, dass dieser Abschnitt für den gesamten Artikel sehr wichtig ist, denn nur allzu häufig werden Vorgehensmodelle um ihrer selbst willen befolgt, unabhängig davon, ob sie in der gegebenen Situation Sinn machen. Auch die negativen Referenzen im letzten Absatz sollten meiner Ansicht nach bestehen bleiben, zeigen sie doch, dass das Prozess- oder Vorgehensmodell eben nicht in der Lage ist, Fehler im Projektmanagement oder der Personalausstattung zu kompensieren.

--J.P.Wagner 13:43, 23. Nov 2005 (CET)

Ich denke ebenfalls, dass der Abschnitt wichtig ist. Vielleicht ist die Kritik überzogen, aber nach dem Lesen des Absatzes ist mir wieder eingefallen, warum mich Prozessmodelle nie so richtig überzeugen konnten: Weil Sie den Faktor Mensch einfach viel zu wenig berücksichtigen.

Es wird im wesentlichen immer so getan, als ob 1 Mann-Stunde immer das gleiche Ergebnis produziert. Dass dies in der Realität nicht der Fall ist und die individuelle Leistungsfähigkeit von Programmieren, bzw. Informatikern enorm unterschiedlich ist, wird nicht einmal erwähnt.

Ich habe mir gerade eine Einführung in CMM (Capability Maturity Model) durchgelesen. Die Tatsache dass das Know-How und die Qualität der individuellen Mitglieder eines Projekt-Teams eine enorme Rolle spielen wird darin völlig übergangen. Im Gegenteil: Nach der Beschreibung ist es ein negatives Merkmal, wenn der Erfolg eines Projekts von einzelnen Projekt-Mitgliedern abhängt (das deutet auf eine Maturity von 1 hin). Mir ist klar, dass es betriebswirtschaftlich gesehen wünschenswert ist, nicht abhängig von einzelnen fähigen Mitarbeitern zu sein; es ist aber verrückt zu glauben, dass man durch den richtigen Prozess völlig unabhängig von der Qualität der technischen Angestellten wird. (Genauso irrig wie die Annahme, dass man einen brillianten Programmierer durch 4 mittelmäßige ersetzen kann.)

--84.154.57.201 08:16, 30. Jan 2006 (CET)

der Abschnitt und der Inhalt ist gut in der argumentation nur grauenhaft formuliert. ich habe moich den ersten beiden abschnitten angenommen und klarer formujliert. den rest wenn ich zeit hab. --141.35.17.32 16:41, 27. Feb 2006 (CET)

Überarbeitung

der Arteikel scheint mir reichlich dünn. Ich halte ihn deshalb für überarbeitungswürdig. -- Abubiju 11:56, 17. Mär 2006 (CET)