Einheitlicher Softwareentwicklungsprozess. Einheitlicher Entwicklungsprozess und extreme Programmierung

Gemäß GOST 34.601-90 „AS. „Stufen der Erstellung“ legt die folgenden Phasen der Erstellung eines AIS fest, die wiederum in Phasen unterteilt werden können:

· Bildung von Anforderungen an AIS;

· Entwicklung des AIS-Konzepts;

· technische Aufgabe;

· vorläufiger Entwurf;

· technisches Projekt;

· Arbeitsdokumentation;

· Inbetriebnahme.

Jede Phase verfügt über eine eigene Entwurfsdokumentation und Implementierung technischer und Softwaremodule des Systems. Die Praxis zeigt, dass der Prozess der Systemerstellung iterativ und inkrementell ist. Dies betonen die Autoren der UML bei der Definition des Konzepts einheitlicher Software- und Informationsentwicklungsprozess. Obwohl in der ersten Phase ein Anforderungskatalog für das AS als Ganzes erstellt wird, ist dieser zu Beginn immer unvollständig und wird in den folgenden Phasen geklärt. Ich muss es tun Iterationen, d.h. einzelne Schritte und Etappen ganz oder teilweise wiederholen. Darüber hinaus ist ein reales System multifunktional und komplex, daher wird es normalerweise in Subsysteme und separate Aufgabensätze unterteilt, wobei Subsysteme und Aufgaben der ersten Stufe, der zweiten usw. unterschieden werden. Das System wird erstellt schrittweise, durch schrittweise Erweiterung der Funktionalität durch den Ersatz vorläufiger Designlösungen durch weiter entwickelte Lösungen, die den Benutzeranforderungen besser entsprechen. Dies reduziert finanzielle Risiken und spart Zeit und Ressourcenverbrauch in der Endphase der Erstellung.

Bei der Verwendung der UML-Methodik zur Erstellung von AIS-Software und Informationsunterstützung wird vorgeschlagen, eine Reihe miteinander verbundener Modelle zu erstellen, die die statischen und dynamischen Eigenschaften des zukünftigen Systems widerspiegeln:

· Anwendungsfallmodell;

· Analysemodell;

· Designmodell;

· Bereitstellungsmodell;

· Implementierungsmodell;

· Testmodell.

Anwendungsfallmodell Enthält Anwendungsfalldiagramme und entsprechende Szenarien, beschreibt die funktionalen Anforderungen des Systems und sein Verhalten bei der Interaktion mit Benutzern.

Analysemodell Enthält generische Klassendiagramme zur Implementierung von Anwendungsfällen auf logischer Ebene, zugehörige Sequenzdiagramme und/oder Kollaborationsdiagramme und ist eine Skizze, wie die Anwendungsfälle auf logischer Ebene implementiert werden.

Designmodell ist eine detaillierte Darstellung der physischen Implementierung des Analysemodells und umfasst Paketdiagramme (Subsystemdiagramme), detaillierte Klassendiagramme, Sequenzdiagramme und/oder Kooperationsdiagramme, Zustandsdiagramme und Aktivitätsdiagramme mit unterschiedlichem Detaillierungsgrad.

Bereitstellungsmodell Enthält vorläufige Bereitstellungsdiagramme, die alle Netzwerkkonfigurationen definieren, auf denen das System ausgeführt werden kann. Bereitstellungsdiagramme zeigen Netzwerkknoten, Verbindungstypen und die Verteilung aktiver Systemklassen unter den Knoten.

Implementierungsmodell beschreibt, wie Designklassen als Komponenten implementiert werden. Dementsprechend enthält es Komponentendiagramme, Klassen-(Implementierungs-)Traces, detaillierte Bereitstellungsdiagramme und eine Beschreibung der Systemarchitektur.

Testmodell enthält eine Reihe von Testfällen, Testverfahren und Beschreibungen von Testkomponenten. Es spezifiziert Methoden zum Testen ausführbarer Systemkomponenten.

Vergleichen wir die Prozesse zum Erstellen von Modellen mit den standardisierten Phasen der Erstellung eines AS. Das Anwendungsfallmodell wird in der Phase der Anforderungsbildung für das AS erstellt; Das Analysemodell befindet sich in der Phase der Entwicklung des AS-Konzepts. In der Phase der technischen Spezifikationen und des Vorentwurfs wird ein Entwurfsmodell erstellt. Es wird in der technischen Entwurfsphase verfeinert und durch ein Bereitstellungsmodell ergänzt. In der Phase der Arbeitsdokumentation werden Implementierungs- und Testmodelle erstellt. Schließlich wird das Testmodell in der Phase der Inbetriebnahme verfeinert und dient während des Betriebs als Referenzmodell, das für regelmäßige Überprüfungen der korrekten Funktion und Diagnose des Systems vorgesehen ist.

1.5 Komponenten der UML-Sprache

Einheitliche Modellierungssprache UML(Unified Modeling Language) ist eine visuelle Modellierungssprache, die zum Spezifizieren, Visualisieren, Konfigurieren und Dokumentieren komplexer Systeme (einschließlich Software) mithilfe objektorientierter Technologie verwendet wird.

Bei der Erstellung eines AS in der UML-Methodik werden die aus den Hein/Sarson- und SADT-Methodiken bekannten Prinzipien der strukturellen Systemanalyse verwendet:

· schrittweise Entwicklung von oben nach unten;

· Diagrammtechnik;

· Hierarchie der Beschreibungen;

· strikte Formalisierung der Beschreibung von Designlösungen;

· anfängliche Entwicklung des Projekts auf logischer Ebene ohne Details zur technischen Umsetzung;

· konzeptionelle Modellierung im Hinblick auf den Themenbereich, damit der Kunde das Systemdesign verstehen kann;

· technologische Unterstützung mit Werkzeugen (CASE-Systeme).

Ein Modell eines komplexen Systems in UML kann untersucht werden, um geschätzte Eigenschaften der Effizienz von Prozessen im System zu erhalten.

Modelle zur Bereitstellung, Implementierung und zum Testen von AS-Software und Informationsunterstützung in UML können als Anwendungsprojekt mit anschließender automatisierter Generierung von Anwendungscode in einer der ausgewählten Programmierumgebungen verwendet werden.

Ein ziemlich vollständiges Modell eines komplexen Systems sollte zwei Aspekte widerspiegeln:

-statisch(strukturell) – Zusammensetzung, Struktur der Komponenten und ihre Beziehungen;

-dynamisch(verhaltensbezogen) – Beschreibung der Logik von Prozessen, die im System ablaufen oder implementiert werden sollen.

Die Hauptmethode zur Darstellung von in UML übernommenen Modellen sind Diagramme, die mit Textinformationen versehen sind, einschließlich Ausdrücken in der integrierten Einschränkungssprache OCL sowie in den Programmier- und Informationsabfragesprachen, die zur Implementierung des Systems verwendet werden.

Das Grundprinzip der Modellierung: Ein System wird als Gruppe diskreter Objekte modelliert, die so miteinander interagieren, dass sie den Benutzeranforderungen entsprechen.

Ein statisches Modell spezifiziert die Struktur, Objekttypen und Beziehungen zwischen Objekten. Das dynamische Modell bestimmt das Verhalten von Objekten im Zeitverlauf (die Geschichte von Objekten) und ihre Interaktion.

Grundsätzlich ist UML eine diskrete Modellierungssprache, das heißt, sie enthält das Konzept diskreter Ereignisse und Zustandsänderungen. Kontinuierliche Prozesse werden näherungsweise durch Diskretisierung modelliert.

Das Modell hat zwei Aspekte: semantische Informationen (Semantik) und visuelle Darstellung (Notation).

Die vollständige Zusammensetzung der Modelldarstellungen in der UML-Sprache ist in Tabelle 1 angegeben

Tabelle 1 – Darstellung von Systemmodellen in UML.

Das gebräuchlichste konzeptionelle Modell eines Systems ist das Anwendungsfalldiagramm; es ist der Ausgangspunkt für die Erstellung anderer Diagramme.

Alle Sprachdiagramme sind Diagramme eines besonderen Typs, die Scheitelpunkte (geometrische Figuren) enthalten, die durch Kanten (Bögen) verbunden sind. Normalerweise sind der Maßstab des Bildes und die Position der Eckpunkte nicht besonders wichtig. Im Sequenzdiagramm wird jedoch die Zeitachse eingeführt, und dort ist sie von Bedeutung.

Verbindungen werden durch verschiedene Linien auf der Ebene angezeigt, Text wird in die Figuren geschrieben und einige grafische Symbole können in der Nähe der Eckpunkte und Verbindungen dargestellt werden. UML-Erweiterungen ermöglichen räumliche Diagramme.

Die Sprache verfügt über 4 Arten von grafischen Strukturen:

· Icons (Piktogramme);

· grafische Symbole auf einer Ebene;

· Pfade (Linien);

· Textzeilen.

1.6 Konzeptionelle Ebene. Anwendungsfallmodell

Im Allgemeinen erfolgt der objektorientierte Designprozess gemäß den Grundprinzipien der strukturellen Systemanalyse: Top-Down-Design mit der Konstruktion einer Hierarchie von Diagrammen, die uns schrittweise von Ebene zu Ebene bewegen: konzeptionell – logisch – physisch (Umsetzung)

Als oberstes Diagramm gilt das von A. Jacobson in OOSE vorgeschlagene Anwendungsfalldiagramm Systeme als Ganzes. Dies ist die anfängliche konzeptionelle Darstellung des Systems und wird mit dem Ziel erstellt:

· die allgemeinen Grenzen und den Kontext des modellierten Themenbereichs bestimmen;

· allgemeine Anforderungen an das Funktionsverhalten und die Schnittstelle des Systems formulieren;

· Bereiten Sie die erste Dokumentation für die Interaktion zwischen Entwicklern und Kunden – Benutzern des Systems – vor.

Sicht des Models: externer Benutzer des Systems. Ein Anwendungsfalldiagramm umfasst Akteure, Anwendungsfälle und Assoziationen.

Akteur(Akteur, externe Entität, Akteur) – eine abstrakte Beschreibung einer Klasse von Nachrichtenquellen/-empfängern, die direkt mit einem System, Subsystem oder einer Klasse interagieren. Dies ist die Beschreibung Rollen gespielt vom Benutzer (Person oder anderes System, Subsystem, Klasse) während der Interaktion mit dem System. Im Wesentlichen handelt es sich dabei um eine Verallgemeinerung ähnlicher Informationsanfragen an das System, die eine bestimmte Anforderung erfordern Service(Dienstleistungen).

Ein Akteur muss nicht unbedingt mit einer bestimmten Person oder einem bestimmten Gerät identifiziert werden, obwohl dies manchmal prinzipiell möglich ist, wenn er nur eine Rolle spielt. In den meisten Fällen handelt es sich – physisch – um verschiedene Personen und Geräte, die auf das System zugreifen, um denselben Dienst zu erhalten. Auf der höchsten Ebene können Akteure beispielsweise ein Bediener, ein Systemadministrator, ein Datenbankadministrator, ein normaler Benutzer oder eine bestimmte Geräteklasse sein.

Alle möglichen Akteure schöpfen alle möglichen Arten der Benutzerinteraktion mit dem System (Subsystem, Klasse) aus. Bei der Implementierung eines Systems werden Aktoren in Menschen und physischen Objekten verkörpert. Eine Person oder ein physisches Objekt kann je nach Art der Interaktion mehrere Akteure (unterschiedliche Rollen) darstellen. Beispielsweise kann dieselbe Person Betreiber und Datenbankadministrator, Verkäufer und Käufer usw. sein.

In vielen AS gibt es außer Menschen keine weiteren Akteure. Die Akteure können jedoch ein externes System, ein E/A-Gerät oder ein Timer sein (üblicherweise in eingebetteten Echtzeitsystemen zu finden). Unter den Akteuren im Anwendungsfall sticht einer hervor Hauptakteur(Hauptakteur), der die Arbeit mit dem System initiiert. Der Rest ist zweitrangig, sie nehmen ebenfalls am Anwendungsfall teil, erhalten Ergebnisse und geben einige Zwischendaten ein.

Auf der logischen und physischen Ebene werden Aktanten durch Klassen und Objekte repräsentiert, die Instanzen von Klassen sind. Es ist möglich, eine Aktantenhierarchie mit der Vererbung aller Rollen und Beziehungen, Attribute und Operationen des Vorfahren-Aktanten aufzubauen. Eine Instanz eines untergeordneten Aktanten kann immer an der Stelle im System verwendet werden, an der die Verwendung des Vorfahren-Aktanten deklariert ist (Substitutionsprinzip).

Ein Aktant kann auf zwei Arten in Diagrammen dargestellt werden:

3. Klassensymbol (Rechteck) mit interner Angabe des Stereotyps

4. Mehr Standard: „Mann“ mit Inschrift (Symbol einer Person)

Der Aktant befindet sich außerhalb des Systems und seine innere Struktur ist nicht bestimmt. Es ist die Quelle/Empfänger von Nachrichten.

Kunde

Anwendungsfall(Präzedenzfall, Anwendungsfall) – eine abstrakte Beschreibung der Serviceklasse (Servicefunktionen), die dem Akteur als Antwort auf seine Anfragen bereitgestellt wird.

Der Dienst kann vom System als Ganzes, einem Subsystem oder einer Klasse bereitgestellt werden. Ein Anwendungsfall bedeutet also die Modellierung eines Teils der Funktionalität oder des Verhaltens eines Systems. Ein Anwendungsfall hat einen Namen und bezeichnet eine bestimmte Abfolge von Aktionen, die für eine externe Quelle/Empfänger (Aktant) sichtbar sind. Die interne Art und Weise der Implementierung der Option wird verborgen und auf niedrigeren Detailebenen offenbart. Kooperationsdiagramm. Wie jede Klasse verfügt auch ein Anwendungsfall über Attribute und Operationen, deren Implementierung auf der physischen Ebene verfügbar gemacht wird.

Der Anwendungsfall umfasst die gesamte Nachrichtenfolge, die der Akteur mit dem System (Subsystem, Klasse) beginnt und endet. Daher hat jede Instanz einer Anwendungsfallimplementierung immer einen zeitlichen Anfang und ein Ende, wenn kein Akteur Nachrichten für diese Option sendet. Dazu gehören auch Fehlermeldungen, Möglichkeiten zur Durchführung der Wartungsfunktion mit verschiedenen Einstellungen (Alternativen).

Eine Anwendungsfallinstanz ist die Ausführung eines Anwendungsfalls, die nach dem ersten Empfang einer Nachricht von einer Akteursinstanz beginnt. Als Reaktion auf eine bestimmte Nachricht führt der Anwendungsfall eine bestimmte Abfolge von Aktionen aus, z. B. das Senden einer Nachricht an andere Instanzen des Akteurs (nicht nur an den Absender). Diese Akteure senden wiederum Nachrichten an diese Anwendungsfallinstanz, und die Interaktion wird fortgesetzt, bis keine solchen Nachrichten mehr empfangen werden. Dies markiert das Ende des Anwendungsfalls.

Der Zusammenhang zwischen Akteur und Anwendungsfall wird aufgezeigt Verband.

Das Diagramm stellt den Anwendungsfall auf zwei Arten dar:

1) eine Ellipse, darin wird ein Name platziert

2) ein Rechteck – wie jede Klasse

Kunde

Sensor

Zwischen Akteuren und Anwendungsfällen ist die Assoziation die einzige Art der Verbindung. Darüber hinaus hat es Semantik Kommunikation umschalten, also die Weitergabe von Nachrichten, wird daher in der Regel nicht gekennzeichnet, da der Kontext aus der Aktanten- und Anwendungsfallnotation klar hervorgeht. Sie können es aber markieren und auch die Vielfältigkeit der Verbindung angeben:

Bankkunde

Vielzahl(Multiplizität) charakterisiert die Anzahl spezifischer Instanzen einer Klasse, die an einer bestimmten Verbindung teilnehmen (ein Kunde kann eine unbegrenzte Anzahl von Krediten vergeben).

Allgemein Verband ist eine Beziehung zwischen zwei oder mehr Modellkomponenten. Da es sich bei Komponenten in den meisten Fällen um bestimmte Klassen von Objekten handelt, handelt es sich bei einer Assoziationsinstanz lediglich um eine geordnete Liste von Verweisen auf bestimmte Instanzen, möglicherweise ausgestattet mit Assoziationsattributen (Eigenschaften).

Der Assoziationsname, sofern vorhanden, muss eindeutig sein. Es wird entsprechend der Bedeutung der Beziehungen zwischen den am Verein beteiligten Klassen gebildet. Beispiel: „Mitarbeiter arbeitet in Abteilungsleiter" vervollständigt Computer“ usw.

Assoziationen sind selbst Klassen ( Assoziationsklasse, Assoziationsklasse), verfügt sie sowohl über Klassen- als auch über Assoziationseigenschaften. Instanzen dieser Klasse sind Verbindungen, die nicht nur Verknüpfungen zu Objekten, sondern auch Attribut-(Eigenschafts-)Werte aufweisen.

Die Mitglieder des Vereins werden als „It“ bezeichnet Stangen. Alle Pole sind die Rollen der an der Verbindung beteiligten Klassen, sie sind unterschiedlich und können in einer geordneten Liste aufgeführt werden. In den meisten Fällen sind Assoziationen binär (zwei Rollen in einer Assoziation mit einer bestimmten Semantik), aber es kann auch so sein N -ary. Ein und dieselbe Klasse kann in unterschiedlichen Rollen agieren, also gleichzeitig in zwei Polen der Assoziation stehen.

An den Polen ist die Vielzahl der Verbindungen angegeben.

Während des Betriebs des Systems können Verbindungen auftreten und verschwinden; an den Polen der Assoziation können Einschränkungen und entsprechende Prädikate angegeben werden.

Manchmal ändert sich die Verbindung nur an einem der Pole. Verfügt ein Link über Attribute, so können diese durch Operationen geändert werden, die Links zu den Linkteilnehmern ändern sich jedoch nicht.

Eine Assoziation wird als durchgehende Linie dargestellt, die die Grenzen zweier Klassen der Assoziation verbindet N-ary, dann wird eine Raute gezeichnet (ein Zeichen der Aggregation):

		Viele Verbände - Anhäufung
	Binäre Assoziation

Anwendungsfälle tauschen keine Nachrichten untereinander aus und können nur in Beziehungen (Verbindungen) stehen. Erweiterungen(verlängern) Aufnahme(einschließen) und Verallgemeinerungen(Verallgemeinerung).

IN bezüglich der Erweiterung Anwendungsfall – der Kunde führt eine zusätzliche Folge von Aktionen ein, beginnend an einem Punkt in der Hauptfolge, und es kann mehrere solcher „Einfügungen“ geben. Alle diese Punkte werden aufgerufen Erweiterungspunkte.

Rational Unified Process (RUP) ist eine der besten Softwareentwicklungsmethoden, die von Rational Software entwickelt wurde. Basierend auf der Erfahrung vieler erfolgreicher Softwareprojekte ermöglicht Ihnen der Unified Process die Erstellung komplexer Softwaresysteme auf Basis industrieller Entwicklungsmethoden. Eine der Hauptsäulen, auf die RUP setzt, ist der Prozess der Modellerstellung mithilfe der Unified Modeling Language (UML). In diesem Artikel geht es um die Verwendung von UML-Diagrammen im Softwaresystem-Entwicklungsworkflow unter Verwendung der Rational Software-Methodik.

Es ist kein Geheimnis, dass die Erstellung von Software ein komplexer Prozess ist, der einerseits viel mit Kreativität zu tun hat und andererseits zwar ein hochprofitables, aber auch kostenintensives Geschäft ist. Der starke Wettbewerb auf dem Markt zwingt Entwickler dazu, nach effizienteren Arbeitsmethoden zu suchen. Möglichkeiten, Softwaresysteme noch schneller, kostengünstiger und mit besserer Qualität zu erstellen. Die Komplexität von Programmen nimmt ständig zu. Bis vor Kurzem konnten Softwareprodukte in absehbarer Zeit von Einzelpersonen oder beispielsweise in der IT-Abteilung eines automatisierten Unternehmens erstellt werden.

Heutzutage bleibt den Leuten, die Programme auf den Knien erstellen, der Bereich kleiner Dienstprogramme und verschiedener Erweiterungsmodule für „schwere“ Softwareprodukte. Die Zukunft gehört dem industriellen Ansatz zur Softwareerstellung. Im Jahr 1913 brachte Henry Ford die erste Automobilmontagelinie auf den Markt, und in den 90er Jahren begann man, eine ähnliche Montagelinie im Bereich der IT-Technologien einzusetzen. Teamentwicklung erfordert einen völlig anderen Ansatz und eine andere Methodik, die früher oder später erstellt werden musste.

Rational Software Corporation (http://www.rational.com) hat eine strukturierte Wissensdatenbank namens Rational Unified Process (RUP) veröffentlicht, die eine Reihe umfassender Empfehlungen für die Erstellung nahezu aller Softwareprodukte enthält. RUP hat die Erfahrung der besten Entwicklungen gesammelt und sagt detailliert, wann, wer und was im Projekt getan werden sollte, um am Ende ein Softwaresystem mit einer bestimmten Funktionalität und innerhalb des zugewiesenen Budgets zu erhalten.

Der einheitliche Prozess kann als die Summe der verschiedenen Aktivitäten des Entwicklungsunternehmens betrachtet werden, die erforderlich sind, um Kundenanforderungen in ein Softwaresystem zu übersetzen. Ein System, das den Benutzern „aussagekräftige Ergebnisse“ liefert und genau das tut, was sie vom System erwarten. Daher wird der Prozess durch Anwendungsfälle des Systems oder auf andere Weise durch Präzedenzfälle gesteuert.

Um Kundenanforderungen rechtzeitig umzusetzen, ist der Unified Process in Phasen unterteilt, die aus Iterationen bestehen, weshalb der Prozess auch als iterativ und inkrementell bezeichnet wird. Jede Iteration durchläuft einen Zyklus grundlegender Arbeit und führt die Entwickler zum endgültigen Ziel: der Erstellung eines Softwaresystems. Bei Iterationen entstehen Zwischenartefakte, die für den erfolgreichen Abschluss des Projekts erforderlich sind, und eine Version des Softwaresystems, die einen bestimmten Satz von Funktionen implementiert, der von Iteration zu Iteration zunimmt. Die Phasen und Hauptabläufe des Prozesses sind in Abb. dargestellt. In Abb. 1 sind dort auch die ungefähren Arbeitskosten der Arbeiten pro Phase angegeben.

Reis. 1 RUP-Phasen und Arbeitsabläufe

Es ist zu beachten, dass in Abb. 1 zeigt nur die Hauptarbeit des Unified Process. Aktivitätsmanagementaktivitäten werden hier beispielsweise nicht angezeigt, um das Diagramm nicht zu überladen.

Die gesamte Softwareentwicklung wird in RUP als Prozess der Erstellung von Artefakten betrachtet. Jedes Ergebnis des Projekts, seien es Quellcodes, Objektmodule, an den Benutzer übertragene Dokumente, Modelle – dies sind Unterklassen aller Projektartefakte. Jedes Mitglied des Projektteams erstellt seine eigenen Artefakte und ist für diese verantwortlich. Der Programmierer erstellt das Programm, der Manager erstellt den Projektplan und der Analyst erstellt die Systemmodelle. Mit RUP können Sie bestimmen, wann, von wem und welches Artefakt erstellt, geändert oder verwendet werden muss.

Eine der interessantesten Klassen von Projektartefakten sind Modelle, die es Entwicklern ermöglichen, Softwaresystemartefakte zu definieren, zu visualisieren, zu konstruieren und zu dokumentieren. Jedes Modell ist eine eigenständige Sicht auf das zu entwickelnde System und soll sowohl Probleme skizzieren als auch Lösungen vorschlagen. Autonomie von Modellen bedeutet, dass ein Analyst oder Entwickler alle benötigten Informationen aus einem bestimmten Modell erhalten kann, ohne auf andere Quellen zurückgreifen zu müssen.

Mithilfe von Modellen können Sie das zukünftige System, seine Objekte und deren Interaktion berücksichtigen, noch bevor Sie erhebliche Mittel in die Entwicklung investieren. Sie ermöglichen es Ihnen, es mit den Augen zukünftiger Benutzer von außen und Entwicklern von innen zu betrachten, noch bevor die erste Quelle erscheint Code wird erstellt. Die meisten Modelle werden durch UML-Diagramme dargestellt. Weitere Informationen zu UML finden Sie beispielsweise in.

Die Unified Modeling Language erschien Ende der 80er und Anfang der 90er Jahre, hauptsächlich dank der Bemühungen der „drei Freunde“ Gradi Bucha, Jim Rambo und Ivar Jacobson. Sie wurde nun vom OMG-Konsortium als Standardmodellierungssprache übernommen, die Entwicklern eine klare Notation bietet, die die Darstellung von Modellen in grafischen Elementen ermöglicht, die allgemein akzeptiert und von allen Projektbeteiligten verstanden werden.

Wir sollten jedoch nicht vergessen, dass die Modellierungssprache nur eine Notation bereitstellt – ein Werkzeug zum Beschreiben und Modellieren eines Systems, und ein einheitlicher Prozess bestimmt die Methodik für die Verwendung dieses Tools sowie anderer Tools zur Methodenunterstützung von Rational. UML kann ohne eine bestimmte Methodik verwendet werden, da es prozessunabhängig ist. Unabhängig davon, welche Prozessoption verwendet wird, können Sie Diagramme verwenden, um die während der Entwicklung getroffenen Entscheidungen zu dokumentieren und die erstellten Modelle anzuzeigen.

Ein Softwaresystem wird geschaffen, um spezifische Benutzerprobleme zu lösen, und nicht für Programmierer, um neue Technologien zu testen und Erfahrungen für den Projektmanager zu sammeln. Im Großen und Ganzen ist es dem Benutzer egal, ob Sie im Entwicklungsprozess einen objektorientierten Ansatz, UML, RUP verwenden oder ein System mit der XP-Methode (Extreme Programming) erstellen. Der Einsatz bestimmter Methoden, Technologien und die Schaffung der optimalen internen Struktur des Projekts liegt im Gewissen der Entwickler, die ihre Entscheidungen auf der Grundlage bisheriger Erfahrungen und eigener Vorlieben treffen. Der Nutzer wird es Ihnen jedoch nicht verzeihen, wenn Sie seine Anforderungen ignorieren. Selbst wenn ein Softwaresystem zehnmal mit modernsten Methoden und Technologien entwickelt wird, wird Ihr Softwareprojekt kläglich scheitern, wenn der Benutzer daraus kein sogenanntes „sinnvolles Ergebnis“ erhält.

Daraus folgt, dass die gedankenlose Anwendung von UML, nur weil sie in Mode ist, nicht nur die Entwicklung nicht zum Erfolg führt, sondern auch zu Unzufriedenheit bei Mitarbeitern führen kann, die eine große Menge zusätzlicher Literatur studieren müssen, und bei Projektmanagern, wenn sich herausstellt, dass dies der Fall ist Die Arbeitskosten für das Projekt steigen und die Erträge steigen nicht. Sie müssen klar verstehen, was Sie durch die Implementierung dieser Technologie erreichen möchten, und dieses Ziel verfolgen. Durch den Einsatz von UML werden Entwicklungsressourcen eingespart, da Sie sich schneller ein Bild vom System machen können als bei der Erstellung von Layouts und Prototypen und dabei unvergleichlich weniger Ressourcen aufwenden müssen.

Diagramme erleichtern den Projektmitgliedern die Kommunikation untereinander und, was besonders wertvoll ist, die Einbeziehung der Endbenutzer des Systems in den Prozess. Durch die Modellierung können Sie Projektrisiken reduzieren, da es für Programmierer immer einfacher ist, das zu tun, was klar und verständlich ist, als zu einem unsicheren Ergebnis zu gelangen. Das Erstellen von Diagrammen ähnelt dem Erstellen eines Projekts im Bauwesen. Sie können beispielsweise darauf verzichten, wenn Sie einen Schuppen auf einem Ferienhaus bauen. Allerdings ist es umso schwieriger, je größer das Gebäude (in unserem Fall ein Softwareprodukt) ist umso unsicherer ist das Endergebnis.

Ich habe einmal ein Seminar zu RUP bei einem Softwareunternehmen gehalten, das seit zehn Jahren recht erfolgreich am Markt war, in seinem Workflow jedoch überhaupt keine Modellierung einsetzte, sondern auf Prototypen basierte. Ungefähr zwanzig junge und erfahrene Programmierer versammelten sich im Saal und hörten aufmerksam zu, was ich ihnen über RUP und UML erzählte. Und einer von ihnen bemerkte beim Blick auf die mit Beispieldiagrammen bedeckte Tafel: „Das ist alles interessant und wahrscheinlich gut für andere Projekte“, sagte er, „aber wir haben schon ziemlich lange ohne all das gearbeitet, seitdem wir es sind.“ Trotzdem haben wir auf UML verzichtet, wahrscheinlich brauchen wir es einfach nicht.“

Diese Frage ließ mich denken, dass die Änderung der Geschäftsprozesse, die in einem Softwareentwicklungsunternehmen bei der Implementierung von RUP und UML zwangsläufig eintreten muss, genauso schwierig sein kann wie die Implementierung eines Informationssystems in einem Industrieunternehmen. Jede Implementierung ist ein Bruch mit Stereotypen. Da die Qualifikation der Mitarbeiter in einem Softwareentwicklungsunternehmen recht hoch ist, ist es für solche Menschen schwieriger, ihre Ansichten aufzugeben als für „Normalsterbliche“, und die dabei auftretenden Schwierigkeiten und Ablehnungen können mit dem Übergang von der prozeduralen zur objektiven Einstellung verglichen werden. orientiertes Denken.

1. Definition der Anforderungen

Ein einheitlicher Prozess ist ein Prozess, der von Anwendungsfällen gesteuert wird, die Benutzerinteraktionsszenarien widerspiegeln. Tatsächlich ist es die Sicht des Benutzers auf das Softwaresystem von außen. Eine der wichtigsten Entwicklungsphasen wird laut RUP daher die Phase der Anforderungsermittlung sein, die darin besteht, alle möglichen Wünsche für den Betrieb des Systems zu sammeln, die Benutzern und Analysten nur in den Sinn kommen können. Später müssen diese Daten systematisiert und strukturiert werden, aber in dieser Phase müssen Analysten durch Interviews mit Benutzern und das Studium von Dokumenten möglichst viele Anforderungen an das zukünftige System sammeln, was nicht so einfach ist, wie es auf den ersten Blick scheint. Nutzer haben oft keine Ahnung, was sie am Ende bekommen sollen. Um diesen Prozess zu erleichtern, verwenden Analysten Anwendungsfalldiagramme (Abb. 2).

Abb. 2. Beispiel eines Anwendungsfalldiagramms

Das Diagramm spiegelt die Akteure (Aktanten) wider, die mit dem System interagieren, und die Reaktion von Softwareobjekten auf ihre Aktionen. Akteure können sowohl Benutzer als auch externe Agenten sein, die Informationen übermitteln oder empfangen müssen. Das Anwendungsfallsymbol spiegelt die Reaktion des Systems auf externe Eingaben wider und zeigt, was für den Akteur getan werden muss.

Um einen bestimmten Anwendungsfall detailliert darzustellen, wird ein Aktivitätsdiagramm verwendet, dessen Beispiel in Abbildung 3 dargestellt ist.

Reis. 3 Beispiel eines Aktivitätsdiagramms

Die Einfachheit des Anwendungsfalldiagramms ermöglicht es Analysten, während des Prozesses der Anforderungsdefinition problemlos mit Kunden zu kommunizieren und Einschränkungen zu identifizieren, die dem System und der Umsetzung einzelner Anforderungen auferlegt werden, wie z. B. der Reaktionszeit des Systems, die später in den Bereich der nichtfunktionalen Anforderungen fallen Anforderungen.

Ein Use-Case-Diagramm kann auch zur Erstellung von Testszenarien verwendet werden, da alle Interaktionen zwischen Benutzern und dem System bereits definiert sind.

Um die Anforderungen richtig zu bestimmen, müssen Entwickler den Kontext (Teil des Themenbereichs) verstehen, in dem das zukünftige System betrieben wird. Dazu werden ein Domänenmodell und ein Geschäftsmodell erstellt, die unterschiedliche Ansätze für dasselbe Problem darstellen. Oftmals entsteht eines: ein Domänenmodell oder ein Geschäftsmodell.

Der Unterschied zwischen diesen Modellen besteht darin, dass das Domänenmodell die wichtigen Konzepte beschreibt, mit denen das System arbeiten wird, und ihre Verbindungen untereinander. Während ein Geschäftsmodell die Geschäftsprozesse (bestehende oder zukünftige) beschreibt, die das System unterstützen soll. Daher definiert dieses Modell nicht nur die am Prozess beteiligten Geschäftsobjekte, sondern auch die Mitarbeiter, ihre Verantwortlichkeiten und die Aktionen, die sie ausführen müssen.

Um ein Domänenmodell zu erstellen, wird ein reguläres Klassendiagramm verwendet (Abbildung 6), aber es reicht eindeutig nicht aus, um ein Geschäftsmodell zu erstellen. In diesem Fall wird ein Anwendungsfalldiagramm mit zusätzlichen Symbolen verwendet, die das Wesentliche von Geschäftsprozessen widerspiegeln – dies sind Geschäftsakteur, Geschäftsanwendungsfall, Geschäftseinheit und Unternehmensführung. Dieses Modell ist dem nächsten im Entwicklungsprozess erstellten Modell – dem Analysemodell – viel näher.

2.Analyse

Nachdem die Anforderungen und der Kontext ermittelt wurden, in dem das System betrieben werden soll, ist es an der Zeit, die erhaltenen Daten zu analysieren. Während des Analyseprozesses wird ein analytisches Modell erstellt, das Entwickler zur Architektur des zukünftigen Systems führt. Ein analytisches Modell ist eine Sicht auf ein System von innen, im Gegensatz zu einem Anwendungsfallmodell, das zeigt, wie das System von außen aussehen wird.

Anhand dieses Modells können Sie verstehen, wie das System gestaltet sein sollte, welche Klassen es haben sollte und wie diese miteinander interagieren sollten. Sein Hauptzweck besteht darin, die Richtung der Implementierung der in der Phase der Anforderungserhebung identifizierten Funktionalität festzulegen und die Systemarchitektur zu skizzieren.

Im Gegensatz zum später erstellten Entwurfsmodell ist das Analysemodell eher ein konzeptionelles Modell und bringt Entwickler nur näher an die Implementierungsklassen heran. Dieses Modell sollte keine möglichen Widersprüche aufweisen, die im Vorgängermodell auftreten können.

Zur Darstellung des Analysemodells mittels UML wird ein Klassendiagramm mit den Stereotypen (Verhaltensmustern) „Grenzklasse“, „Entität“, „Kontrolle“ und zur Detaillierung Kollaborationsdiagramme verwendet (Abbildung 4). Das Stereotyp „Grenzklasse“ stellt eine Klasse dar, die mit externen Akteuren interagiert, das Stereotyp „Entität“ stellt Klassen dar, die Datenspeicher sind, und das Stereotyp „Kontrolle“ stellt Klassen dar, die Abfragen an Entitäten verwalten.

Abbildung 4. Beispiel eines Kollaborationsdiagramms

Die Nummerierung der Nachrichten zeigt ihre Reihenfolge, aber der Zweck des Diagramms besteht nicht darin, die Reihenfolge der ausgetauschten Nachrichten zu berücksichtigen, sondern die Beziehungen der Klassen untereinander klar darzustellen.

Wenn wir uns auf die Reihenfolge der Interaktion konzentrieren, wäre eine andere Darstellung ein Sequenzdiagramm (Sequenz), dargestellt in Abbildung 5. Dieses Diagramm ermöglicht es Ihnen, den Austausch von Nachrichten im Zeitverlauf zu betrachten und die Abfolge des Prozesses visuell darzustellen. Wenn Sie ein Modellerstellungstool wie Rational Rose verwenden, können diese beiden Arten von Diagrammen automatisch voneinander erstellt werden (mehr über Rational Rose können Sie beispielsweise in lesen).

Reis. 5 Beispiel eines Sequenzdiagramms

Die Entscheidung, welches der beiden Diagramme zuerst erstellt wird, hängt von den Vorlieben des einzelnen Entwicklers ab. Da es sich bei diesen Diagrammen um eine Darstellung desselben Prozesses handelt, können Sie mit beiden die Interaktion zwischen Objekten widerspiegeln.

3.Design

Der nächste Schritt im Prozess der Systemerstellung ist der Entwurf, bei dem ein Entwurfsmodell basierend auf den zuvor erstellten Modellen erstellt wird. Dieses Modell spiegelt die physische Implementierung des Systems wider und beschreibt das erstellte Produkt auf Klassen- und Komponentenebene. Im Gegensatz zum Analysemodell weist das Entwurfsmodell eine klare Abhängigkeit von den Implementierungsbedingungen, den verwendeten Programmiersprachen und Komponenten auf. Für ein möglichst genaues Verständnis der Systemarchitektur sollte dieses Modell so formalisiert wie möglich sein und während des gesamten Systementwicklungslebenszyklus auf dem neuesten Stand gehalten werden.

Um ein Designmodell zu erstellen, wird eine ganze Reihe von UML-Diagrammen verwendet: Klassendiagramme (Abb. 5), Kooperationsdiagramme, Interaktionsdiagramme, Aktivitätsdiagramme.

Abb. 6. Beispiel eines Klassendiagramms

Darüber hinaus kann dieser Workflow ein Bereitstellungsmodell erstellen, das auf der Grundlage eines Bereitstellungsdiagramms implementiert wird. Dies ist der einfachste Diagrammtyp zur Modellierung der Geräteverteilung in einem Netzwerk. Für die Anzeige werden lediglich zwei Optionen für die Prozessor- und Gerätesymbole sowie die Verbindungen zwischen ihnen verwendet.

4.Implementierung

Die Hauptaufgabe des Implementierungsprozesses besteht darin, ein System in Form von Komponenten zu erstellen – Programmquellcodes, Skripte, Binärdateien, ausführbare Module usw. In dieser Phase wird ein Implementierungsmodell erstellt, das beschreibt, wie Elemente des Designmodells implementiert werden und welche Klassen in bestimmte Komponenten aufgenommen werden. Dieses Modell beschreibt die Art und Weise der Organisation dieser Komponenten gemäß den in der ausgewählten Programmierumgebung verwendeten Strukturierungs- und Modularisierungsmechanismen und wird durch ein Komponentendiagramm dargestellt (Abb. 7).

Reis. 7 Beispielkomponentendiagramm

5.Testen

Während des Testprozesses werden die Ergebnisse der Implementierung überprüft. Für diesen Prozess wird ein Testmodell erstellt, das aus Testfällen, Testverfahren und Testkomponenten besteht, jedoch keine UML-Diagrammdarstellung aufweist, sodass wir nicht weiter darauf eingehen.

6. Fazit

Hier wurden nur die Hauptprozesse der Rational-Methodik betrachtet. RUP ist recht umfangreich und enthält Empfehlungen für die Durchführung verschiedener Softwareprojekte, von der Erstellung von Programmen durch eine Gruppe von Entwicklern aus mehreren Personen bis hin zu verteilten Softwareprojekten, die Tausende von Menschen auf verschiedenen Kontinenten vereinen. Trotz ihrer enormen Unterschiede sind die Methoden zur Verwendung von mit UML erstellten Modellen jedoch dieselben. UML-Diagramme, die in verschiedenen Entwicklungsstadien erstellt werden, sind untrennbar mit den übrigen Artefakten eines Softwareprojekts verbunden und stellen häufig die Verbindung zwischen einzelnen RUP-Prozessen dar.

Die Entscheidung, bestimmte Diagramme zu verwenden, hängt vom im Unternehmen eingerichteten Entwicklungsprozess ab, der zwar als einheitlich bezeichnet wird, aber nicht eingefroren ist. Rational bietet nicht nur Verbesserungen und Verfeinerungen an, sondern stellt auch spezielle Tools für Änderungen an der RUP-Datenbank bereit.

Aber in jedem Fall ermöglicht Ihnen die Verwendung von UML zusammen mit einem einheitlichen Prozess, ein vorhersehbares Ergebnis zu erzielen, das zugewiesene Budget einzuhalten, die Wirkung der Projektteilnehmer zu erhöhen und die Qualität des erstellten Softwareprodukts zu erhöhen.

Kratchen. F. Einführung Rationaler einheitlicher Prozess . Ed. 2. – M.: Williams Publishing House, 2002. – 240 Seiten: Abb.

Jacobson A., Buch G., Rambo J. Einheitlicher Softwareentwicklungsprozess – St. Petersburg: Peter, 2002. – 496 Seiten: Abb.

Fowler M., Scott K. UML auf den Punkt gebracht. Anwendung einer Standard-Objektmodellierungssprache: Transl. aus dem Englischen – M.:Mir, 1999. – 191 S., mit Abb.

Beck. E. Extreme Programmierung. – St. Petersburg: Peter, 2002. – 224 S.: Abb.

TrofimovS. CASE-Technologien: Praktische Arbeit in Rational Rose.
Ed. 2. - M.: Binom-Press, 2002 - 288 S.

Unified Process nutzt aktiv die einheitliche Modellierungssprache ( UML). Im Kern UML dahinter steckt ein Modell, das es dem Entwicklungsteam ermöglicht, die Vielfalt komplexer Prozesse, die für die Softwareentwicklung erforderlich sind, auf vereinfachte Weise zu verstehen. Verschiedene Modelle im Einsatz Einheitlicher Prozess ermöglichen Ihnen, das System zu visualisieren, seine Struktur und sein Verhalten zu beschreiben und Entscheidungen zu dokumentieren, die während des Entwicklungsprozesses getroffen wurden.

Entstehungsgeschichte

Die Ursprünge des Frameworks liegen in der Arbeit eines Mitarbeiters Ericsson Ivar Jacobson, veröffentlicht Ende der 1960er Jahre. Jacobson und seine Kollegen modellierten riesige Telekommunikationssysteme mithilfe von Schichten aus „Blöcken“ (die später als „Komponenten“ bekannt wurden): Die unteren Schichten dienten als Grundlage für Subsysteme aus den oberen Schichten. Das Team baute die unteren Blöcke unter Berücksichtigung von „Verkehrsfällen“, die Benutzern des Systems passieren könnten. Es waren diese „Vorfälle“, die zum Prototyp von Anwendungsfällen wurden, die später einbezogen wurden UML. Jacobsons Arbeit inspirierte auch die Erstellung von Diagrammen, die in verwendet werden UML, einschließlich Aktivitäts- und Sequenzdiagrammen .

1987 gründete Jacobson sein eigenes Unternehmen Objectory AB und entwickelte zusammen mit Partnern mehrere Jahre lang ein Projekt und Produkt namens Einspruch. 1995 veröffentlichte Jacobson das Buch „ Objektorientierte Softwareentwicklung“ beschreibt einen Entwicklungsprozess, der von Kundenanforderungen gesteuert wird, die durch Anwendungsfälle in das Endprodukt umgesetzt werden. Die Veröffentlichung des Buches fiel mit der ersten Veröffentlichung der Online-Version des Kernels zusammen Einheitlicher Prozess.

Im Jahr 1995 wurde das Unternehmen Objectory AB von der Körperschaft übernommen Rational. Mit Hilfe einer deutlich größeren Zahl von Kollegen beginnt Jacobson, den Prozess auszubauen Einspruch, ergänzt durch Tools für Projektmanagement und -entwicklung. Zusammen mit Grady Booch und James Rumbaugh, die dort arbeiteten Rational Zuvor war Jacobson Mitglied der Gruppe der „drei Amigos“, die die Arbeit zur Schaffung eines Prozesses namens „Three Amigos“ leiteten Rationeller Einspruchsprozess (ROP), sowie die Verteilung Einheitlicher Prozess, was die Grundlage für wurde Einheitliche Modellierungssprache.

Im Prozess der Arbeit daran ROP Und UML, Konzern Rational fortgesetzte Fusionen und Übernahmen von Unternehmen, die sich mit der Entwicklung von Softwareentwicklungstools befassen. Diese Tools stellten Funktionen für Anforderungsmanagement („RequisitePro“), allgemeine Tests („SQA“), Leistungstests, Konfigurationsmanagement und Änderungsmanagement bereit. In 1998 Rationaländert den Produktnamen in RUP, dessen konzeptioneller Kern erhalten bleibt Einheitlicher Prozess.

Eigenschaften

Einheitlicher Prozess bezogen auf Anwendungsfälle, beschreibt einen oder mehrere Akteure, die mit dem System interagieren und Ergebnisse erzielen, die für die Prozessteilnehmer wertvoll sind. Es sind Anwendungsfälle, die die Hauptantriebskraft für den gesamten Entwicklungsprozess sind, angefangen bei der Erfassung und Diskussion der Anforderungen bis hin zur Analyse, dem Design und der Implementierung. Anwendungsfälle werden in einfacher und verständlicher Sprache beschrieben, sodass sie auch für einen externen Leser verständlich sind.

Entsprechend Einheitlicher Prozess, im Zentrum des Entwicklungsprozesses steht die Architektur- die grundlegende Organisation des gesamten Systems. Es kann statische und dynamische Elemente sowie deren Interaktion umfassen und ermöglicht die Lösung von Problemen der Produkteffizienz, Erweiterbarkeit und der Fähigkeit zur Wiederverwendung von Elementen sowie die Überwindung wirtschaftlicher und technischer Einschränkungen. Das Projektteam beginnt so früh wie möglich mit der Arbeit an der Architekturbeschreibung und erweitert und verbessert diese im Laufe des Entwicklungsprozesses kontinuierlich. Architektur wird als wichtiger Aspekt angesehen Einheitlicher Prozess Aus einer Reihe von Gründen, deren Schlüssel die Fähigkeit sind, das Gesamtbild des Geschehens zu sehen, die korrekte Anwendung der Entwicklerbemühungen, die Erleichterung von Möglichkeiten zur Wiederverwendung von Komponenten, die Systementwicklung und die richtige Auswahl von Anwendungsfällen.

Das dritte Grundprinzip Einheitlicher Prozess ist der Nutzen iterativer und inkrementeller Ansatz. Iterationen sind Miniaturprojekte, die es Ihnen ermöglichen, eine neuere Version des Systems zu starten. Das Ergebnis der Iteration, also die am System vorgenommenen Änderungen, wird als Inkrement bezeichnet. Insbesondere der iterative Ansatz ermöglicht es Ihnen, die Systemarchitektur kontinuierlich zu verbessern, sich ständig ändernde Anforderungen zu bewältigen und den Plan des gesamten Projekts flexibel anzupassen. Das Bekenntnis zum Prinzip der kontinuierlichen Integration ermöglicht es Ihnen, mögliche Probleme frühzeitig zu erkennen. Darüber hinaus trägt die Iteration dazu bei, Risiken im Zusammenhang mit technischen Einschränkungen, der Architektur und sich ändernden Anforderungen zu minimieren.

Entwicklungsphasen

Relative Größe der Entwicklungsphasen für ein typisches Projekt

Jeder Entwicklungszyklus, entsprechend Einheitlicher Prozess, besteht aus vier Phasen, die den Zeitraum zwischen wichtigen Projektmeilensteinen darstellen und es Managern ermöglichen, wichtige Entscheidungen hinsichtlich der Fortsetzung des Entwicklungsprozesses, des Arbeitsumfangs, des Budgets und des Zeitplans zu treffen.

Workflow-Varianten

Innen Einheitlicher Prozess In jeder Entwicklungsphase gibt es fünf Arten von Arbeitsprozessen: Anforderungen, Analyse, Design, Implementierung und Test.

Jeder Prozess besteht aus einer Reihe von Aktivitäten, die von verschiedenen Mitgliedern des Projektteams ausgeführt werden. Das Ziel von Anforderungserfassungsprozessen besteht daher darin, ein Modell von Anwendungsfällen zu erstellen, das es ermöglicht, die grundlegenden Funktionsanforderungen für das System zu identifizieren. Analyseprozesse und das entsprechende Modell ermöglichen es Entwicklern, funktionale Anforderungen zu strukturieren; Der Designprozess beschreibt die physische Umsetzung der Anwendungsfälle und ist eine Abstraktion für das folgende Modell. Der Implementierungsprozess und das Modell beschreiben, wie sich Designelemente auf Softwarekomponenten beziehen, einschließlich Quellcode, dynamischen Bibliotheken usw. Das letzte Modell, das Tests beschreibt, erklärt, welche Systemtests und Komponententests durchgeführt werden sollten und wie das Entwicklungsteam sie durchführen sollte.

Iterationen und Inkremente

Jede der im Einheitlichen Prozess beschriebenen Phasen besteht aus Iterationen, bei denen es sich um Miniatur-Teilprojekte von begrenzter Dauer handelt. Normalerweise umfasst jede Iteration alle fünf Elemente des Workflows in unterschiedlichem Ausmaß. Das Ergebnis der Iteration ist Zuwachs, eine Version, die Verbesserungen im Vergleich zur vorherigen Version des Produkts enthält.

Rationaler einheitlicher Prozess(RUP) ist ein Software-Entwicklungstechnologie-Framework, das von Rational Software entwickelt und vermarktet wird. Es umfasst globale Best Practices in der Softwareentwicklung und bietet einen disziplinären Ansatz für die Zuweisung und Verwaltung von Aufgaben und Verantwortlichkeiten innerhalb einer Softwareentwicklungsorganisation. Durch die Anwendung dieses Prozesses können Softwareentwicklungsteams qualitativ hochwertige Software erstellen, die den Anforderungen ihrer Endbenutzer entspricht, und dies innerhalb eines vorhersehbaren Zeitplans und Budgets.

RUP unterstützt Softwareprofis bei der effektiven Anwendung aktueller Best Practices wie z iterative Entwicklung, Anwendung Architekturzentrierter Ansatz, Anwendungsfälle, Risikominderung in allen Phasen des Prozesses und kontinuierliche Programmüberprüfung.

Der Rational Unified Process basiert auf mehreren Grundprinzipien, die aus vielen erfolgreichen Projekten stammen:

· Beginnen Sie früher mit dem Angriff auf die Hauptrisiken und führen Sie ihn kontinuierlich durch, sonst gehen sie selbst in die Offensive gegen Sie.

· Stellen Sie sicher, dass die Kundenanforderungen erfüllt werden.

· Konzentrieren Sie sich auf das ausgeführte Programm.

· Passen Sie sich von Beginn des Projekts an an Veränderungen an.

· Richten Sie frühzeitig eine ausführbare Architektur ein.

· Bauen Sie ein System aus Komponenten auf.

·Arbeiten Sie als Team zusammen.

· Machen Sie Qualität zu einer Lebensart und nicht zu einem nachträglichen Gedanken.

RUP verwendet iterativer Ansatz, Jede Iteration erfordert ein wenig Anforderungsarbeit, Analyse, Design, Implementierung und Tests. Jede Iteration baut auf den Ergebnissen vorheriger Iterationen auf und erzeugt ein ausführbares Programm, das dem Endprodukt einen Schritt näher kommt.

RUP bietet strukturierter Ansatz zur iterativen Entwicklung, wobei das Projekt in vier Phasen unterteilt wird: Konzeption, Design, Konstruktion und Implementierung. Jede Phase wird von einem sogenannten Meilenstein begleitet, einem Kontrollpunkt des Prozesses, an dem die Erreichung der Ziele der nächsten Phase überprüft und über den Übergang (oder nicht) in die nächste Phase entschieden wird. Jede der vier Phasen des RUP hat somit einen Meilenstein und klar definierte Ziele. Anhand dieser Ziele wird bestimmt, welche Aufgaben ausgeführt und welche Artefakte erstellt werden sollen. Jede Phase konzentriert sich strikt auf das, was nur notwendig ist, um die Geschäftsziele der Phase zu erreichen.

Alle Prozesselemente - Rollen, Aufgaben, Artefakte und die damit verbundenen Konzepte, Leitfäden und Vorlagen gruppiert in logische Container namens Disziplinen(Disziplinen). Im Standard-RUP-Produkt gibt es nur neun Disziplinen. Dazu gehören: Geschäftsmodellierung, Anforderungsmanagement, Projektmanagement, Änderungsmanagement und Umwelt.

Jeder Prozessablauf: Anforderungserfassung, Analyse, Entwurf, Implementierung und Test definiert eine Reihe zugehöriger Artefakte und Aktivitäten. Denken Sie daran, dass ein Artefakt ein Dokument, ein Bericht, ein ausführbares Element usw. ist. Artefakt produziert, verarbeitet oder konsumiert werden können.

Modell- die wichtigste Art von Artefakten. Es werden neun Modelle bereitgestellt, die zusammen alle Lösungen zur Visualisierung, Spezifikation, Gestaltung und Dokumentation von Softwaresystemen abdecken:

· Geschäftsmodell. Definiert die Abstraktion der Organisation, für die das System erstellt wird;

· Domänenmodell. Korrigiert die kontextbezogene Umgebung des Systems;

· Modellanwendungsfall. Definiert funktionale Anforderungen an das System.

· Analysemodell. Interpretiert Systemanforderungen im Hinblick auf das Designmodell;

· Designmodell. Definiert das Domänenvokabular des Problems und seiner Lösung;

· Platzierungsmodell. Definiert die Hardwaretopologie, in der das System ausgeführt wird.

· Umsetzungsmodell. Definiert die Teile, die zum Zusammenbau und zur Implementierung eines physischen Systems verwendet werden;

· Testmodell. Definiert Testfälle zum Testen des Systems;

· Prozessmodell. Definiert Parallelität im System und Synchronisationsmechanismen.

Technische Artefakte sind in vier Hauptgruppen unterteilt:

· Satz von Anforderungen. Beschreibt Was das System sollte es tun;

· Design-Set.

· Reihe von Implementierungen. Beschreibt den Zusammenbau entwickelter Softwarekomponenten;

· Platzierungsset. Bietet alle Informationen zur gelieferten Konfiguration.

Satz von Anforderungen kann ein Anwendungsfallmodell, ein nichtfunktionales Anforderungsmodell, ein Domänenmodell, ein Analysemodell und andere Formen der Darstellung von Benutzerbedürfnissen umfassen.

Design-Set kann ein Entwurfsmodell, ein Testmodell und andere Formen umfassen, um das Wesentliche des Systems auszudrücken.

Satz von Implementierungen gruppiert alle Daten über die Softwareelemente, aus denen das System besteht (Programmcode, Konfigurationsdateien, Datendateien, Softwarekomponenten, Informationen zur Systemmontage).

Platzierungsset fasst alle Informationen zu Verpackung, Versand, Installation und Inbetriebnahme des Systems zusammen.

Jeder technologische Prozess wird begleitet Risiko. Bei der Entwicklung eines Softwareprodukts kann ein unbefriedigendes Ergebnis (UN) sein: Überschreitung des Budgets, geringe Zuverlässigkeit, fehlerhafte Funktion usw. Die Auswirkung des Risikos wird mithilfe des Ausdrucks berechnet

Risikoindikator = Wahrscheinlichkeit (LP) * Verlust (LP).

Risikomanagement umfasst sechs Aktionen:

1. Risikoidentifizierung – Identifizierung von Risikoelementen im Projekt.

2. Risikoanalyse – Bewertung der Wahrscheinlichkeit und des Ausmaßes des Verlusts für jedes Risikoelement.

3. Risikoeinstufung – Reihenfolge der Risikoelemente nach dem Grad ihres Einflusses.

4. Risikomanagementplanung – Vorbereitung auf den Umgang mit jedem Risikoelement.

5. Risikolösung – Beseitigung oder Lösung von Risikoelementen.

6. Risikoüberwachung – Verfolgung der Dynamik von Risikoelementen und Ergreifen von Korrekturmaßnahmen.

Die ersten drei Maßnahmen gehören zur Risikobewertungsphase, die letzten drei Maßnahmen zur Risikokontrollphase.

Es gibt drei Kategorien von Risikoquellen: Projektrisiko, technisches Risiko und kommerzielles Risiko. Nach der Identifizierung von Risikoelementen sollten deren Auswirkungen auf das Softwareprojekt quantitativ bewertet und Fragen zu möglichen Verlusten geklärt werden. Diese Probleme werden im Rahmen der Risikoanalyse behandelt. Und schließlich wird ein Plan zur Verwaltung jedes Risikoelements, also eine Reihe von Funktionen zur Verwaltung jedes Risikoelements, in den Gesamtplan des Softwareprojekts integriert.