Diskussion:Fachkonzept

Letzter Kommentar: vor 16 Jahren von Avron in Abschnitt überarbeiten

Quellen fehlen

Bearbeiten

Der Artikel strozt nicht unbedingt vor Fachwissen. Näheres findet sich in:

  • Helmut Balzert / Lehrbuch der Software Technik
  • Ernst Denert / Software engineering

hab momentan keine Bib vor der Tür um das Zeuch zuholen! --217.231.246.78 15:41, 17. Apr. 2007 (CEST)Beantworten

Eine Schwäche des Artikels ist, dass Beispiel und Begriffsklärung vermengt sind. Ich selbst habe beruflich viel mit "Fachkonzepten" zu tun, und die Definition passt nur sehr ungenau. Der Bezug zu Projektmanagementmodellen (Wirtschaftsinformatik) fehlt leider völlig. Als Praktiker kenne ich die Quelle des Begriffs nicht genau. Ich weiss aber das Balzert/Denert diesen Begriff in ihrem IT-Projektmodell bewußt prägen, um eine schärfere Trennlinie zwischen IT und Business zu ziehen. Der Begriff Pflichtenheft wird u.a. in die Begriffe Fachkonzept (system specification, system design(V-Model)) und IV-Konzept (system design, architecture & modul design(V-Model)) zerlegt, um die Softwareingenieurleistung von der Prozessgestaltung stärker zu entkoppeln. Das Lastenheft heißt manchmal auch Grobkonzept (system proposal). Es fehlt mir aber auch an den Quellen. Das Mapping auf englische Begriffe ist u.a. leider modellabhängig (siehe "Waterfall Model" engl. Wikipedia), das kann LEO nicht.... Folgende Definition wäre ein neuer Startpunkt (Rautenstrauch, Uni Magdeburg) Fachkonzept: (semi-)formale, implementierungsunabhängige Beschreibung einer betriebswirtschaftlichen Konzeption --Benutzer:karuu 12:00, 4. Dec. 2007(CEST)

Lastenheft

Bearbeiten

Ich war mal so frei und habe folgenden Kommentar aus dem Artikel (!!) entfernt

"Mitunter wird auch der Begriff Lastenheft synonym verwendet."

Total falsch, das Fachkonzept hat wenn das Synonym Pflichtenheft. Das Pflichtenheft beschreibt WAS gemacht wird, und das Fachkonzept beschreibt WAS UND WIE. Sprich das Fachkonzept beeinhaltet das Pflichtenheft. --80.136.115.91 10:23, 3. Mär 2006 (CET)

Egal wie eindeutig die Begriffe sein mögen: ich habe den Eindruck, dass in der Praxis kaum ein einheitliches Verständnis vorherrscht! Wie seht ihr das?
Ich denke, wir sollten uns weniger der akademischen Richtigkeit und mehr der allgemeinen Verständlichkeit hingeben. Habt ihr Vorschläge zur Begriffsklärung?
--Beschloss 22:27, 12. Mär 2006 (CET)
Die Informationstechnik ist international. Warum gibt es im Englischen ( Leo ) keine Übersetzung für "Fachkonzept"? Kann es sein, dass "Fachkonzept" etwas typisch "Deutsches" ist, bzw. aus unserer (Behörden-)Kultur und Denken entspringt. Können andere Kulturen auch ohne "Fachkonzept" ein erfolgreiches "Projekt" machen? (nicht signierter Beitrag von 193.197.150.210 (Diskussion) )
(1) Ich kenne auch deutsche Grosskonzerne die den Begriff Fachkonzept verwenden (also nicht nur Behörden...).
(2) Ich schätze LEO zwar auch, aber acuh LEO ist nicht allumfassend.
(3) Der Nachsatz ist wohl nur Polemik: Egal wie man das Kind nennt: eine fachliche Spezifikation ist immer erforderlich.
--Beschloss 21:45, 11. Jun 2006 (CEST)
Um sich dem Begriff zu nähern ist eine Möglichkeit den "Kunden" für das "Fachkonzept" ( Who is the customer ? ) zu indentifizieren. Dann ist der Wert, den es für den Kunden hat ( Which value does it add to the project? ) herauszuarbeiten.Wäre es möglich sich dabei auf diese Beispiele der Grosskonzerne zu beziehen und an einem Muster die Spezifika herauszuarbeiten und dann zu verallgemeinern? Ich bin mit dem Begriff schon oft konfrontiert worden. Die einzige Art der Wertschöpfung, zu der ein solches Fachkonzept verwendet wurde, war die des Ablassbriefes für kommende Sündenstrafen. Es ist schlecht wenn man dann keinen Ablassbrief hat. Dann wird man bestraft.....Hätten Sie mal ein Fachkonzept gehabt....Was daran gut ist, wozu man es braucht, erschließt sich mir nicht. Nach meiner Einschätzung geht dieser Begriff in dem Begriff "Konzeption" voll auf. (nicht signierter Beitrag von 193.197.150.210 (Diskussion) )

Zweifel an "UML für Anforderungen"

Bearbeiten

Die Aussage "Anforderungen mit UML beschreiben" habe ich schon oft gehört. Auf Nachfragen, wie das denn gehen solle, habe ich aber keine ernstzunehmenden Antworten bekommen, die über das Malen von Flussdiagrammen hinausgingen. Die Aussage stammt vermutlich aus Werbe-Broschüren.

Doch jetzt mal konstruktiv: Anforderungen müssen in der Sprache der Anforderungssteller verfasst sein. Sonst können sie von letzteren nicht verantwortet werden. Und bei jeder Anforderung muss klar beschrieben werden, wie der Auftraggeber das Ergebnis der Arbeit daraufhin prüfen wird, ob es die Anforderung erfüllt.

Wie UML hierbei helfen soll ist mir in 15 Jahren UML-Praxis (bis 1996: OOA) bisher nicht klar geworden.

Dennoch ist UML nicht gänzlich wertlos bei der Anforderungsaufnahme: Bei größeren Anforderungssammlungen (>50 Anforderungen) hat es sich bewährt, die einzelnen Absichten, mit denen Anwender an das beschriebene System herantreten, als Use Cases zu dokumentieren und diesen wiederum in einer m:n-Beziehung die o.g. Anforderungen zuzuordnen. Das hat sehr dazu beigetragen, Übersichtlichkeit herzustellen.

Fazit: Die Aussage, dass UML benutzt wird, um Anforderungen zu beschreiben, möchte ich gerne aus dem Artikel entfernen. Und vielleicht durch etwas praxisnähere Beschreibungen ersetzen.

Ich bitte um Kommentare.

Martin Wagenleiter (martin at wagenleiter dot de), geb. Rösch

Beispiel "Datenbank"

Bearbeiten

Ich finde das Beispiel mit der Datenbank etwas unglücklich - Datenbanken sind technische Mittel zur Speicherung von Informationen. Fachkonzepte wurden aber (zu recht) gerade dadurch definiert, dass sie keine technischen Angaben/Einschränkungen enthalten sollen. Es gibt zwar sicherlich in speziellen Fällen auch Begründungen für ein Fachkonzept für Datenbanken, aber das als Beispiel zu verwenden ist verwirrend oder sogar irreführend. --Vanda1 08:53, 19. Sep 2006 (CEST)

überarbeiten

Bearbeiten

Es ist so wie in der Praxis, schon der erste Satz ist schwammig: Das Fachkonzept ist der wichtigste Vorlauf einerseits zur Systemspezifikation und andererseits dem fachlichen Betriebshandbuch. Der Rest des Artikels ist genauso schlimm.-- Avron 20:35, 23. Jul. 2008 (CEST)Beantworten

Im Internet gibt es viel Rauschen, wenig brauchbare. Hier einige Links: [1], [2], [3], [4] --Avron 09:16, 24. Jul. 2008 (CEST)Beantworten

Ja der erste Satz war so kaum zu gebrauchen. Hat das mal formuliert. Entsprechend habe ich den Verweis auf Nachfolgedokumente in den Nachsatz verschoben. Gruss ollio 22:21, 24. Jul. 2008 (CEST)Beantworten
Ich habe die Einleitung nun komplett umgeschrieben.--Avron 11:36, 28. Jul. 2008 (CEST)Beantworten