Lade Inhalt...

Die Erstellung eines Lasten- und eines Pflichtenheftes als Grundlage für die Individual-Softwarelösung „Holzfirma“

Beispielhafte Darstellung von ERMs als erstes Umsetzungsergebnis der Anforderungsdefinition

Diplomarbeit 2002 81 Seiten

Informatik - Wirtschaftsinformatik

Leseprobe

Inhaltsverzeichnis

1 Erläuterung und Abgrenzung des Themas
1.1 Aufgabe und Ziel der Arbeit
1.2 Ausgangssituation und Aufgabenabgrenzung
1.3 Darstellung der persönlichen Stellung des Verfassers zum KMU „Industrie- holz Krieger, Kufstein“

2 Verwendete Methoden und Verfahren
2.1 Die Phasen der Softwareentwicklung
2.2 Werkzeuge bei der Analyse und Anforderungsdefinition
2.2.1 Die Theorie des Geschäftsprozesses und genutzte Darstellungsmethoden
2.2.2 Das Lastenheft und das Pflichtenheft
2.2.3 Die Entity-Relationship-Modellierung
2.3 Die Begriffe Individual- und Standardsoftware
2.4 Die Dateiverwaltung „Microsoft ACCESS“

3 KMU und ihre Bedeutung in einer Marktwirtschaft
3.1 Die Abgrenzung des Begriffes „KMU“
3.2 Die volkswirtschaftliche Bedeutung von KMU in Österreich
3.3 Die Bedeutung von Informationstechnologien für KMU
3.4 Geschäftsaktivitäten des Unternehmens „Industrieholz Krieger, Kufstein“

4 Die Geschäftsprozessanalyse im KMU „Industrieholz Krieger“ als Basis für die Anforderungsdefinition
4.1 Der Bereich „Einkauf“
4.2 Der Bereich „Lagerwirtschaft“
4.3 Der Bereich „Verkauf“
4.4 Der Bereich „Kaufmännische Verwaltung“

5 Das Lastenheft „Holzfirma“

6 Das Pflichtenheft „Holzfirma“

7 Darstellung wichtiger ER-Modelle
7.1 Der Wareneingang
7.2 Der Warenausgang
7.3 Die Debitoren
7.4 Die Kreditoren
7.5 Das Rechnungswesen

8 Das MS-ACCESS-Programm „Holzfirma“ – ein Ausblick auf das An- wendungsprogramm

9 Die grundsätzliche Beurteilung des Einsatzes von Individualsoft- ware in KMU

Anlagen

Abkürzungsverzeichnis

Literaturverzeichnis

Anlagenverzeichnis

Eidesstattliche Erklärung

1 Erläuterung und Abgrenzung des Themas

1.1 Aufgabe und Ziel der Arbeit

Das mittelständische Tiroler Unternehmen „Industrieholz Krieger, Kufstein“ (nachfolgend „IHK“ genannt) möchte die betrieblichen verwaltungstech-nischen Tätigkeiten durch die Einführung einer einfachen und preis-günstigen IT-Lösung rationalisieren. Auf der Grundlage einer bereits er-folgten Teilanalyse von ausgewählten Geschäftsprozessen (vgl. dazu SCHMIDT 2002) und den am Markt verfügbaren Softwareprodukten wurde innerbetrieblich entschieden, dass eine Individualsoftware eingeführt wer-den soll. Die vorliegende Diplomarbeit wird ein Lasten- und ein Pflichten-heft für dieses Projekt „Holzfirma“ erarbeiten. Neben diesem zentralen Punkt werden die benutzten Methoden und Werkzeuge des Software Engineering bei der Zielerreichung vorgestellt sowie die besondere wirt-schaftliche Bedeutung von KMU diskutiert. Mittels Vorgangskettendia-grammen und Funktionsbäumen werden Ergebnisse der Geschäftspro-zessanalyse als Basis für die anschließende Definitionsphase dargestellt. Nach Vorliegen von Lasten- und Pflichtenheft werden einige zentrale Entity-Relationship-Modelle definiert sowie ein kurzer Ausblick auf die Be-nutzeroberfläche des Programms „Holzfirma“ gegeben.

1.2 Ausgangssituation und Aufgabenabgrenzung

Für eine nachhaltige Entwicklung von Unternehmen spielen neben der fachlichen Seite im Geschäftsprozess immer mehr das Informations-management und eine effiziente Verwaltung eine entscheidende Rolle. Wenn sich Qualität und Preis der angebotenen Produkte infolge der Kon-kurrenz immer ähnlicher werden, so gilt es nun Wege zu finden, um sich dennoch von den Mitbewerbern zu unterscheiden. Ein schnelles Reagie-ren auf Kundenwünsche und eine fehlerfreie Abwicklung aller „Bürotätig-keiten“ sind erfolgversprechende Wege dazu. Im Zusammenhang mit einem umfassenden Customer Relationship Management heißt es dazu : „Oft wird übersehen, dass es nur weniger unzufriedenstellender Reak-tionen seitens des Unternehmens und seiner Mitarbeiter bedarf, um den Entschluss zur Beendigung von Geschäftsbeziehungen reifen zu lassen – speziell seit das Internet die Konkurrenz gleich frei Haus liefert. ...Nicht mehr die Produkte sind das Zentrum der Geschäftstätigkeit, sondern die Kunden.“ (o. V. IN : NOVUM 2002, 17). Insbesondere für KMU heißt das, dass Stärken wie Meisterschaft, Flexibilität und Individualität auf fachlicher Ebene durch Professionalität bei der Kundenbetreuung, d.h. im Verwal-tungssektor, abzurunden sind. Zwar umfasst der Begriff des CRM viel mehr als nur die büromäßige Verwaltungstätigkeit des betrieblichen Lei-stungsprozesses, aber als wesentliches Kernelement beim Eingehen auf Kundenbedürfnisse stellt genau diese Verwaltungstätigkeit einen entschei-denden Ansatzpunkt unter den Bedingungen eines Käufermarktes dar. Eine falsch ausgestellte Rechnung, eine fehlerhafte Auftragsbearbeitung oder versäumte Termine werden seitens des Kunden nicht toleriert, weil die Primärleistung (also das eigentliche Produkt oder die Dienstleistung) relativ schnell von einem Mitbewerber erbracht werden könnte. Folglich liegt auch in der Sekundärleistung (das sind die den Leistungsprozess unterstützenden Verwaltungstätigkeiten) ein Schlüssel zum nachhaltigen Unternehmenserfolg.

Die Ausführung von verwaltungstechnischen Bürotätigkeiten kann durch den Einsatz der Computertechnologie wesentlich unterstützt werden. Der Einsatz von Computern hat z.B. Einfluss auf die Qualität und Schnelligkeit der Erledigung der anstehenden Bürotätigkeiten, und er beeinflusst auch den Produktionsfaktor „Personal“. Einerseits werden bestimmte Mindest-anforderungen an die Ausbildung und das fachliche Grundwissen des Per-sonals gestellt. Andererseits ist der Einsatz von Computertechnologie ge-eignet, menschliche Arbeitskraft rationeller einzusetzen und stellt somit einen Intensivierungsfaktor mit hohem Rationalisierungspotenzial dar.

Um dieses Rationalisierungspotenzial sinnvoll und zielgerichtet auch in KMU einzusetzen, ist ein absolutes Augenmerk auf die personellen und fi-nanziellen Mindestanforderungen des Computereinsatzes zu richten. Ein zu teures System, das die Einsatzmöglichkeiten im konkreten Unter-nehmen technisch weit übertrifft, immense Wartungskosten verschlingt oder den Einsatz hochqualifizierten Personals erfordert, stellt keine Ratio-nalisierungsquelle dar, sondern kann den Einsparungseffekt von Res-sourcen im Unternehmen negativ beeinflussen.

Gerade für KMU bis zu einer bestimmten Größe, Mitarbeiteranzahl oder Finanzkraft ist deshalb der Einsatz von am Markt erhältlichen professionel-len Systemen, Hard- oder Softwarekomponenten nicht realisierbar. Diese Komponenten sind entweder zu teuer, erfordern hochqualifiziertes Perso-nal oder widerspiegeln nicht in erforderlichem Maße das abzubildende Be-triebsgeschehen. Einen Ausweg bietet der Einsatz von individuell erstellter betrieblicher Software, die auf handelsüblichen und preisgünstigen Stan-dard-Office-Paketen basieren ( z.B. von Microsoft oder Lotus). Diese Lösungen können relativ preiswert selber erarbeitet werden, laufen auf normalen „Kaufhaus-PC´s“ und sind auch von Personal mit PC-Grund-lagenwissen anwendbar. Ein weiterer Vorteil solcher Lösungen ist es, dass z.B. branchenunübliche Betriebsabläufe, Organisationsstrukturen oder sonstige Besonderheiten softwaremäßig abgebildet werden können, was bei Nutzung von neutraler Standardsoftware nicht oder nur nach er-heblichem finanziellen Anpassungsaufwand möglich wäre. Nachteilig da-gegen ist die Begrenzung des Multi-User-Einsatzes, fehlende Schnittstel-len zu Outside-Solutions und technische Grenzen der Software hinsicht-lich Datenbestandsvolumen und –verarbeitung.

Die vorliegende Diplomarbeit befasst sich schwerpunktmäßig mit Elemen-ten der Anforderungs- und Definitionsphase im Prozess des Software Engineering von Individualsoftware für das Tiroler KMU „IHK“. Es wird zunächst auf die theoretischen Grundlagen bei der Erstellung von Software eingegangen und der Begriff der „Klein- und Mittelunternehmen“ im Zusammenhang mit der österreichischen Volkswirtschaft diskutiert. Die Darstellung von Geschäftsprozessen des KMU „IHK“ bildet anschließend die Grundlage für die Erarbeitung eines Lastenheftes sowie eines Pflichtenheftes für das Softwareprojekt „Holzfirma“ des Unternehmens. Die Geschäftsprozessanalyse basiert dabei teilweise auf der entsprechenden Hausarbeit des Verfassers im Frühjahr 2002. Das im Rahmen der Di-plomarbeit zu erstellende Lasten- und Pflichtenheft soll die praxisrelevante Grundlage für die weitere Arbeit bei der Erstellung des eigentlichen Pro-gramms bilden. Aufbauend auf den Anforderungen des Pflichtenheftes werden für einige wichtige Geschäftsprozesse Entity-Relationship-Models generiert. Den Abschluss der Diplomarbeit bilden Darstellungen der Be-nutzeroberfläche des Programms „Holzfirma“ sowie eine grundsätzliche Einschätzung von Individualsoftware für KMU´s.

1.3 Darstellung der persönlichen Stellung des Verfassers zum KMU „Industrieholz Krieger, Kufstein“

Der Verfasser dieser Diplomarbeit ist als Betriebswirt in dem genannten Unternehmen tätig. Neben allen kaufmännischen Belangen des Unterneh-mens ist er auch für alle Fragen der Informationstechnologie verantwort-lich. Aus dieser besonderen Situation als Angestellter leitet sich die tiefe Durchdringung des Betriebsgeschehens ab : für Außenstehende schwer erkennbare Besonderheiten im täglichen Leistungs- und Verwaltungsab-lauf des Unternehmens können infolge der eigenen Betroffenheit im Ar-beitsprozess identifiziert und auf ihre Zweckmäßigkeit hin beurteilt wer-den. Da andererseits die Tätigkeit in dem Unternehmen noch nicht lange besteht, ist die Gefahr der „Betriebsblindheit“ sowie die Scheu vor der Hinterfragung von Geschäftsprozessen auf ihre Effizienz und ihren Sinn und die nachfolgende Erarbeitung von Veränderungsvorschlägen bis hin zum Business Reengineering oder Change Management ausgeschlossen.

2 Verwendete Methoden und Verfahren

2.1 Die Phasen der Softwareentwicklung

Die Entwicklung von Software ist ein Prozess, bei dem es darum geht, für ein existierendes Problem der realen Welt ein funktionierendes Computer-programm zu schaffen und erfolgreich zu installieren. Das Programm muss dabei zieldefiniert sein, bestimmten Qualitätsanforderungen genü-gen und sich auf seine Wirtschaftlichkeit – sowohl in Bezug auf die Ent-wicklung als auch in Bezug auf den tagtäglichen Betrieb – überprüfen las-sen. „Die Softwarekosten dominieren inzwischen die Kosten der Hardware bei weitem.“ (PAGEL / SIX 1994, 43). Diese Aussage stammt zwar aus dem Jahre 1994, trifft aber heutzutage mehr denn je zu. Eine Einteilung von IT-Projekten zur Softwarebeschaffung aus dem Jahre 1999 gibt als untere Größenordnung für ein einfaches Projekt (z.B. eine Abteilungsan-wendung) ein Investitionsvolumen bis zu Euro 15.000 vor. Mittlere In-vestitionssummen für Software bewegen sich bis zu Euro 150.000, von der oberen Größenordnung wird ab Euro 250.000 gesprochen (vgl. GRUPP 1999, 43 f.). Woher kommen diese Kosten ? Und was haben diese Kosten mit den Phasen der Softwareentwicklung zu tun ? Der Pro-zess der Softwareentwicklung ist ein hochgradig komplexes und arbeits-teiliges Gebilde, das neben einem materiell-technischen Ressourcenein-satz auch einen ganz erheblichen Aufwand an hochqualifiziertem Personal und Arbeitszeit verursacht. Um diesen Vorgang beherrschen zu können, hat es sich als effektiv erwiesen, den Gesamtprozess zu unterteilen, zu strukturieren und Zielvorgaben zu fixieren. Diese Phaseneinteilung im Prozess der Softwareerstellung ermöglicht es, Arbeitspakete, Ziele, Mei-lensteine und Verantwortlichkeiten zu definieren, Arbeitsgruppen zu ko-ordinieren, Zeitrahmen und materielle sowie finanzielle Ressourcen fest-zulegen und zu kontrollieren. Die Phaseneinteilung hat demnach zwei Zielrichtungen : einmal die fachliche und zum anderen eine wirtschaftliche Seite. Alle im Zusammenhang mit der Erstellung von Software ablaufen-den Aktivitäten können unter Beachtung von diversen Kriterien wie z.B. Zeit, Zwischenergebnis usw. in Phasen zusammengefasst werden. Das schafft eine organisatorisch-theoretische Grundlage, den Gesamtprozess transparenter zu machen und ihn fachlich und finanziell aktiv zu beherr-schen.

Folgende Grobeinteilung ist allgemein anerkannt :

(1) Analysephase (Problemanalyse und Planung)
(2) Definitionsphase (Anforderungsdefinition und Systemspezifikation)
(3) Entwurfsphase (System- und Komponentenentwurf)
(4) Implementierungsphase (Implementierung und Tests)
(5) Abnahme- und Einführungsphase (Einführung beim Anwender)
(6) Wartungsphase (Fehlerbehebung, Änderungen, Anpassungen)

(vgl. STANIEROWSKI o. J., a, 17 f.).

Dieses 6-Phasen-Modell basiert weitgehend auf dem Vorgehensmodell zur Anwendungsentwicklung von RIEMANN, der Vorschlagsphase, Defi-nitionsphase, Konzeptphase, Entwurfsphase, Realisierungsphase, Ein-führungs- und Implementierungsphase unterscheidet (RIEMANN 1996)[1].

Vielfach ist auch eine Zusammenfassung der genannten Einzelphasen an-zutreffen. So werden z.B. die beiden ersten Phasen unter dem englischen Begriff „requirements engineering“ oder „requirements analysis and speci-fication“ als „A&D-Phase“ (Anforderungs- und Definitionsphase) zusam-mengefasst. Danach beginnt diese A&D-Phase bei der Ermittlung und Analyse der Aufgabenstellung und endet mit der Anforderungsdefinition für das System (vgl. KÜHNEL et al. 1987, 334 – 335). Wieder andere Ein-teilungen berücksichtigen die interessengeprägte Sicht auf die eigene In-volvierung in den Prozess des SE, so dass z.B. die Abnahme- und Ein-führungs- sowie die Wartungsphase nicht zur eigentlichen Softwareent-wicklung gehören, sondern bereits dem weiteren Software-Lebenszyklus zuzuordnen wären. Wichtig ist, dass eine Phaseneinteilung ein theore-tisches Grundgerüst sein kann, um den Arbeitsablauf der Softwareent-wicklung zu fördern.

Nachfolgend werden die Ergebnisse genannt, mit denen die einzelnen Phasen abschließen können (teilweise sind auch synonyme Begriffe ge-bräuchlich).

Abbildung in dieser Leseprobe nicht enthalten

Tab. 1: Ziele und Ergebnisse der einzelnen Software-Entwicklungsphasen (vgl. STANIE- ROWSKI o. J., a, 17 f.)

Die Anforderungs- und die Definitionsphase sollen kurz näher erläutert werden, weil sie die vorliegende Arbeit besonders betreffen. Es wird aner-kannt, dass ein Scheitern eines Softwareprojektes zum größten Teil be-reits in der A&D-Phase verursacht wird. So sollen ca. 60% des Gesamtrisi-kos bei der Softwarebeschaffung auf unzureichende oder fehlerhafte An-forderungsdefinitionen entfallen (vg. GRUPP 1999, 28). In einer europa-weiten Marktuntersuchung durch das IT-Beratungsunternehmen Diebold wurde festgestellt, dass in der Praxis etwa ein Viertel aller IT-Projekte scheitern; bei jährlichen Gesamtausgaben in Europa von 140,5 Milliarden Dollar sind das immerhin ca. 35 Mrd. Dollar Verlust ! Als wesentliche Ur-sache dafür wird ein Basieren des Projekts auf falschen Geschäftsmodel-len identifiziert (vgl. o. V., a, 2002). Die Universität Dublin kommt in einer anderen Studie zu dem Ergebnis, dass sogar jedes zweite IT-Projekt miss-lingt oder zum Abbruch führt. Von den verbleibenden erfolgreichen Projek-ten werden 40% nur unter beträchtlichen Folgeinvestitionen zum Erfolg geführt (vgl. o. V., b, 2002). Welche Zahlen auch immer richtig sind, eine Grundaussage ist erkennbar : IT-Projekte sind mit einem enormen Risiko verbunden ! Die finanzielle Belastung des Unternehmens durch ein miss-lungenes Projekt kann dabei gewaltige Ausmaße annehmen. So musste z. B. ein gemeinsames Projekt der Hotelketten Hilton und Marriott mit der Mietwagenfirma Budget im Jahre 1994 abgebrochen werden, übrig blie-ben Stranded Costs von 125 Millionen Dollar ! Die britische Child Support Agency verlor durch den Abbruch eines Projektes 1997 allein 600 Mil-lionen Pfund (vgl. o. V., b, 2002). Leider sind keine genauen Angaben verfügbar, inwieweit diese gescheiterten IT-Projekte softwarebedingt waren, auch ist nicht belegt, welche Bedeutung letztendlich eine mangel-hafte A&D-Phase für die genannten Fehlschläge hatte. Wenn jedoch die o. g. Aussagen zu den „falschen Geschäftsmodellen“ usw. auch nur an-satzweise zutreffen, dann muss man die besondere Bedeutung der A&D-Phase anerkennen !

Während in der Entwurfs-, Implementierungs-, Einführungs- und War-tungsphase ein Qualifikationsschwerpunkt des verantwortlichen Personals auf informatikspezifischem Gebiet liegt, so sind insbesondere in der A&D-Phase Fähigkeiten gefragt, die es ermöglichen, die im späteren Programm abzubildende Realität zu durchschauen und modellhaft zu beschreiben. Zwei Fragen sind dabei signifikant :

a) Wie sieht die Ausgangssituation aus, was läuft derzeit wie, wann, wo und womit ab ?
b) Was ist das Wunschziel, was will der Anwender zukünftig eigentlich mit der IT-Lösung machen, was soll sie ihm bringen ?

Hier geht es um ein „...Analysieren des Problems und das Definieren (bzw. Spezifizieren) des Produkts.“ (PAGEL / SIX 1994, 77). Auf der Basis dieser Informationen kann dann die eigentliche Umsetzung des Problems erfolgen. Zusammenfassend kann man festhalten :

1) Die A&D-Phase beschäftigt sich mit den realen Prozessen, die beim Anwender stattfinden.
2) Die A&D-Phase schafft die Grundlage für die weitere Tätigkeit des IT-Spezialisten.
3) Die A&D-Phase wird vorrangig nicht vom IT-Spezialisten, sondern vom Analytiker und Anwender geprägt.
4) Damit der IT-Spezialisten zielführend arbeiten kann, muss die A&D-Phase qualitativ ausreichende Ergebnisse bereitstellen.
5) Sind die Ergebnisse der A&D-Phase unvollständig oder anderweitig mangelhaft, so sind Spätfolgen in Form von unzureichenden Lö-sungen zu erwarten.
6) Nur so exakt, wie das Produkt und seine zu erfüllenden Aufgaben definiert werden, kann auch die Umsetzung erfolgen.

Beendet ist die A&D-Phase, „...wenn die Anforderungen an das Produkt in der Produktdefinition[2] (synonym: Anforderungsdefinition, Aufgabendefi-nition, Pflichtenheft, Requirementkatalog) dokumentiert und verabschiedet sind. ...Adressaten der Produktdefinition sind neben den Entscheidungs-trägern bei Auftraggeber und Auftragnehmer auch die Entwurfsspezia-listen, die auf Basis der Produktdefinition das Innenverhalten und die Architektur der Software festlegen.“ (PAGEL / SIX 1994, 85).

Es muss an dieser Stelle aber erwähnt werden, dass das phasenstruktu-rierte Vorgehen in der Softwareentwicklung auch kritisch diskutiert wird. Als Schwachpunkte werden vor allem unscharfe Phasengrenzen, Proble-me bei der Beurteilung von Phasenergebnissen, zu starke Formalisierung und Bürokratisierung des Gesamtentwicklungsprozesses und unzu-reichende Einflussmöglichkeiten der Anwender auf das Endprodukt und daraus resultierende hohe Wartungskosten genannt. Als Alternativen zum Phasenmodell gelten Werkzeuge wie z.B. Prototyping, Objektorientierung oder der Einsatz von CASE-Tools (vgl. SCHUMANN o. J., 21 ff.).

2.2 Werkzeuge bei der Analyse und Anforderungsdefinition

2.2.1 Die Theorie des Geschäftsprozesses und genutzte Darstel-lungsmöglichkeiten

Um ein komplexes System zu beschreiben, werden Modelle benutzt. Da-bei abstrahiert man von für den Betrachtungszweck unwesentlichen Sei-ten der Gesamtheit und führt eine „...Datenreduktion auf die wesentlichen systemrelevanten Schlüsselkomponenten.“ durch (VESTER 1999, 183). Ein betriebliches Unternehmen stellt sich theoretisch zunächst einmal als ein Gebilde dar, das unterschiedliche Komponenten technischer, perso-neller, sozialökonomischer, finanzieller sowie vieler weiterer Arten in sich vereint. Je nach Zielstellung der Untersuchung und Modellierung eines Betriebes werden die interessierenden Seiten herausgestellt, die nicht in-teressierenden Seiten werden negiert. Ein im Software Engineering (ins-besondere in der Analysephase) verbreitetes Modellierungsverfahren der betrieblichen Realität ist die grafische Darstellung von Geschäftsprozes-sen.

Ein Geschäftsprozess (engl.: business process) stellt eine Kombination von innerbetrieblichen Aktivitäten und Tätigkeiten dar, die mit einem be-stimmten Eingang (Input) beginnen und mit einem geplanten Ergebnis

(Output) abschließen. „A process is a specific ordering of work activities across time and place, with a beginning, an end, and clearly identified in-puts and outputs: a structure of action.” (DAVENPORT 1993)[3]. Dabei geht es aber immer um die Erfüllung der betrieblichen Gesamtaufgabe, also um die Befriedigung eventueller Marktbedürfnisse. So können Geschäftspro-zesse – je nach Abstraktionsniveau – einen direkten Bezug zum externen Kunden (also zum Markt) aufweisen. Genauso können sie aber auch Pro-zesse sein, deren Ergebnis wiederum die Voraussetzung für einen nach-folgenden innerbetrieblichen Prozess darstellt. Dieser nachfolgende inner-betriebliche Prozess stellt seinerseits auch einen Kunden dar : den „inter-nen“ Kunden. Ein interner Kunde existiert nicht zum bloßen Selbstzweck, sondern ist im Leistungserstellungsprozess ein notwendiger Zwischen-schritt auf dem Weg zum externen Kunden. „Die Summe aller miteinander verketteten Geschäftsprozesse einer Unternehmung bildet den Leistungs-erstellungsprozess (Wertschöpfungskette).“ (STANIEROWSKI o. J., 16). Mit dieser „Verkettung“ kommt der Bezug zum externen Kunden klar zum Ausdruck : ein Prozess findet nach dem Effektivitätsprinzip marktwirt-schaftlicher Bedingungen nur dann statt, wenn es eine Möglichkeit der Re-alisierung der Gesamtleistung am Markt gibt. Die nachfolgende Abb.1 zeigt den Bezug von Geschäftsprozessen zu jeweils einem internen und einem externen Kunden. Doch wie kann man nun eine sinnvolle Ge-schäftsprozesseinteilung realisieren, wo beginnt, wo endet ein Geschäfts-prozess im konkreten Beispiel ? Albrecht versteht unter einem Ge-schäftsprozess „...die Zusammenfassung von sachlich zusammengehö-rigen, einzelnen Funktionen, z.B. Warenbeschaffung. Die Definition bzw. Identifizierung von Geschäftsprozessen kann in Unternehmen bewirken, dass eine funktions- oder abteilungsorientierte Sicht durch eine zielorientierte Sicht abgelöst wird. Geschäftsprozesse lassen sich sehr genau beschreiben, da es einen definierten Anfangs- und Eckpunkt und eine Aufgabe gibt, die zu erfüllen ist. Je einfacher Geschäftsprozesse sind, desto schneller können sie ablaufen.“ (ALBRECHT et al. 1999, 47).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Geschäftsprozesse mit internem und externen Kunden

Eine Unternehmung kann grundsätzlich in eine Aufbau- und eine Ablaufor-ganisation unterschieden werden. Während die Aufbauorganisation die Struktur des Unternehmens betrifft und somit einen relativ stabilen oder auch statischen Charakter trägt, sollen mit der Ablauforganisation die dy-namischen Prozesse – also die eigentlichen Geschäftsprozesse – erfasst werden (vgl. BALZERT 1998, 694 f.). Für die Modellierung von Geschäfts-prozessen kommen dabei diverse grafische Verfahren und Diagramme zum Einsatz. Wichtige Vertreter sind u.a. das Interaktions- und Vorgangs-Schema „SOM“ von Ferstl und Sinz, das Aufgabenkettendiagramm „PRO-MET“ von Institut für Wirtschaftinformatik der Hochschule St. Gallen, Petri-Netz-basierte Modelle sowie die ereignisgesteuerten Prozessketten (EPK) und Vorgangsketten-Diagramme (VKD) im Rahmen des ARIS-Systems (Architektur integrierter Informationssysteme) von Scheer (vgl. RUMP 1999, 23 – 32 und Scheer 1997). Die angesprochene Aufbauorganisation dagegen kann z.B. mittels Organigrammen visualisiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Beispiel für ein ARIS-Vorgangskettendiagramm (VKD) (SCHEER 1997, 18)

Die im Betrieb ablaufenden Prozesse vollziehen sich zwischen dem Be-schaffungs- und dem Absatzmarkt. Grundsätzlich kann dabei nach güter-wirtschaftlichen, finanzwirtschaftlichen und informationellen Prozessen unterschieden werden (vgl. OLFERT / RAHN 1994, 27 ff.). Wie diese drei Seiten der betrieblichen Aktivitäten miteinander in Beziehung stehen, kann relativ einfach und dabei doch sehr anschaulich mittels der genannten ARIS-Werkzeuge dargestellt werden (siehe Abb. 2). Aus diesem Grunde wurden für die Geschäftsprozessmodellierung des KMU „Industrieholz Krieger“ Techniken des ARIS-Modells verwendet.

2.2.2 Das Lastenheft und das Pflichtenheft

Der Schwerpunkt der vorliegenden Arbeit betrifft – unter Zugrundelegung des 6-Phasen-Modells – Ergebnisse der ersten beiden Phasen : Analyse- und Definitionsphase (siehe Tab. 1 auf Seite 9 - 10). Zunächst soll ein Lastenheft erstellt werden, das die anwenderseitigen Wünsche und Anfor-derungen an das Programm „Holzfirma“ beschreibt. Dabei wird von der Ist-Situation im Unternehmen ausgegangen und eine „Vision“ der vom spä-teren Programm zu erfüllenden Aufgaben entwickelt. Das Lastenheft, auch als Produktskizze bezeichnet, stellt eine systematische, strukturierte Auf-zählung der Wünsche und Anforderungen des Anwenders an das neue System dar. Ausgehend vom Bedarf des Anwenders werden innerhalb einer sogenannten Vorstudie die meist noch vagen Vorstellungen eruiert und aufgezeichnet. Ein Lastenheft ist die „Zusammenstellung aller Anfor-derungen des Auftraggebers hinsichtlich Liefer- und Leistungsumfang. Im Lastenheft wird definiert, WAS und WOFÜR[4] zu lösen ist. Es dient als Ausschreibungs-, Angebots- und/ oder Vertragsgrundlage. Hier sollten das Thema und die Ziele der Projektarbeit deutlich werden.“ (THORSTENT 2002).

Darauf aufbauend wird ein Pflichtenheft erarbeitet, das die Anforderungen des Lastenheftes berücksichtigt und eine Produktdefinition liefert, die als verpflichtendes Dokument den weiteren Prozess der Softwareerstellung begründet. Dieses Pflichtenheft kann dabei – je nach Umfang des zu er-stellenden Programms – große Dimensionen annehmen. „Die Größe und Komplexität heutiger Softwareentwicklungen ziehen umfangreiche und komplizierte Produktdefinitionen nach sich, welche das menschliche Be-urteilungsvermögen...überfordern.“ (PAGEL / SIX 1994, 47). Das Pflich-tenheft als sehr komplexes Dokument dient dabei zunächst einmal als fachlicher Wegweiser bei der Realisierung des Softwareprojektes. Außer-dem besitzt es auch Bedeutung als juristische Vertragsgrundlage zwischen Auftraggeber und Auftragnehmer. Sollte es nämlich im Zusam-menhang mit dem Projekt zu Streitigkeiten kommen, so kann anhand des von den Vertragsparteien unterzeichneten Pflichtenheftes überprüft wer-den, ob eine Vertragsverletzung vorliegt oder nicht. Im Punkt 2.1 wurden einige Beispiele für gescheiterte IT-Projekte mit ihren finanziellen Auswir-kungen geschildert. Bei diesen Dimensionen wird deutlich, welche immen-se Bedeutung einem Pflichtenheft für die Klärung einer eventuellen Schuldfrage nebst Schadensersatzforderung zukommen kann.

Als das zentrale Dokument des Gesamtprojekts besitzt die Produktdefini-tion, also das Pflichtenheft, eine entscheidende Bedeutung (vgl. PAGEL / SIX 1994, 47 und 79 f.). Es ist eine „Beschreibung der Realisierung aller Anforderungen des Lastenheftes. Im Pflichtenheft wird definiert, WIE und WOMIT[5] die Anforderungen zu realisieren sind. Es dient als verbindliche Vereinbarung für die Realisierung uns Abwicklung des Projektes für Auf-traggeber und Auftragnehmer. Das Pflichtenheft enthält das Lastenheft. Die Ergänzung beinhaltet insbesondere einen Verlaufsplan.“ (THOR-STENT 2002). Inwieweit den Vorstellungen zur Einbeziehung des Lasten-heftes und des Verlaufsplanes in der betrieblichen Praxis gefolgt wird, bleibt dem Anwender überlassen. GRUPP beispielsweise kombiniert Lasten- und Pflichtenheft als Ausschreibungsgrundlage zur externen Soft-warebeschaffung unter dem Gesamtbegriff „Pflichtenheft“ und gibt nur einen zeitlichen Realisierungsrahmen vor (vgl. GRUPP 1999, 124 ff.). Ent-scheidend ist, dass das Pflichtenheft Anforderungen nach Vollständigkeit, Eindeutigkeit und Widerspruchsfreiheit genügen muss. Inwieweit formale Spezifikationen integriert werden, hängt vom jeweiligen Einzelfall ab. Alle Angaben müssen weiterhin nachvollziehbar und validierbar sein (vgl. PA-GEL / SIX 1994, 85 f.). Für weitere Informationen wird auch auf die VDI / VDE-Richtlinien 2519 und 3694 verwiesen (siehe Anlage 1 und 2).

2.2.3 Die Entity-Relationship-Modellierung

Ausgehend von der Anforderungsanalyse für ein zu erschaffendes Daten-banksystem wird im Rahmen des konzeptionellen Entwurfs ein seman-tisches Datenmodell erstellt. Die Datenmodellierung beinhaltet dabei die Erfassung und Beschreibung von Objekten (als Erscheinungen der realen Welt) und der zwischen diesen Objekten existierenden Beziehungen (vgl. RIEMANN o. J., 6 f.). Die Entity-Relationship-Modellierung wurde 1976 von Peter Chen entwickelt und ist ein besonderes Verfahren zur gra-fischen Darstellung von komplexen Datenwelten. Sie verwendet zwei Grundelemente (Entities und Relationships) und liefert einfache und ver-ständliche Strukturen in der Modellierung. Ein Vorteil besteht darin, dass sich die Ergebnisse relativ einfach auf relationale Datenbanksysteme (wie auf das für die vorliegende Arbeit relevante DBS „MS-ACCESS“) übertra-gen lassen (vgl. SCHIEMANN-LILLIE o. J., 19 ff.). Als Ergebnis der ER-Modellierung entsteht ein konzeptionelles Modell, das weitgehend gegen eventuelle Veränderungen der Funktionalität stabil ist (vgl. TIEMEYER / KONOPASEK 2001, 56). Das ERM von Chen ist vielfach modifiziert und ergänzt worden. So zielte es ursprünglich nicht auf die Benutzung als Ba-sis von Datenbanksystemen, sondern sollte lediglich „...als Beschrei-bungssprache für die vorgelagerte Modellierung der Datenstruktur...“ die-nen (RAUH / STICKEL 1997, 17). Dementsprechend machte Chen vor-rangig Aussagen zu Entities und Relationships und gab nur bruchstück-hafte Definitionen von Operationen. Gerade diese Erweiterung um Opera-tionen aber macht die ER-Modellierung vielseitiger einsetzbar und ermög-licht eine bessere Übersichtlichkeit (RAUH / STICKEL 1997, 17 f.). Nach-folgend werden wesentliche ERM-Elemente vorgestellt.

[...]


[1] RIEMANN 1996 (zitiert nach SCHUMANN o.J., 16)

[2] PAGEL / SIX 1994, im Original kursiv

[3] DAVENPORT 1993 (zitiert nach BALZERT 1998, 695)

[4] THORSTENT 2002, im Original Großbuchstaben

[5] THORSTENT 2002, im Original Großbuchstaben

Details

Seiten
81
Jahr
2002
ISBN (eBook)
9783638174589
ISBN (Buch)
9783638717120
Dateigröße
1.3 MB
Sprache
Deutsch
Katalognummer
v11249
Institution / Hochschule
Europäische Fernhochschule Hamburg – FB Wirtschaftsinformatik
Note
1,3
Schlagworte
Software-Engineering Lastenheft Pflichtenheft ERM Individualsoftware

Autor

Teilen

Zurück

Titel: Die Erstellung eines Lasten- und eines Pflichtenheftes als Grundlage für die Individual-Softwarelösung „Holzfirma“