Erinnerung an den vorherigen Vortrag... Unser vorheriger Vortrag war der visuellen Modellierung im Analyse- und Designprozess und den Grundlagen der UML-Sprache gewidmet. Gleichzeitig haben wir zunächst zur Einführung kurz wiederholt: – ein typisches Schema zur Lösung von Problemen mithilfe der Computertechnologie; – Grundbestimmungen der Algorithmen- und Objektzerlegung; –Grundsätze des objektbasierten Ansatzes für Analyse und Design. Als nächstes diskutierten wir, was den Bedarf an visueller Modellierung von Softwaresystemen verursachte, und schauten uns die Geschichte der UML-Sprache an.

In Erinnerung an die vorherige Vorlesung wurden dann die Struktur und die Grundkonzepte von UML überprüft und eine Darstellung des Bildungsproblems vorgelegt, die den im Verlauf des Kurses untersuchten Stoff weiter veranschaulichen wird (Ticketreservierungssystem für eine Fluggesellschaft). Abschließend haben wir die UML-Tools ausführlich behandelt für: – visuelle Beschreibung des Funktionsmodells: Akteure, Anwendungsfälle, Anwendungsfalldiagramme, Aktionsdiagramme; – Beschreibungen der Systemstruktur: Klassen, Objekte und Schnittstellen; Pakete, Subsysteme und Komponenten; – Beschreibungen der Beziehungen zwischen den Elementen des Modells: Abhängigkeit, Assoziation, Generalisierung, Implementierung.

Einführung in die MSF-Methodik und historische Referenz... Was ist Methodik? Methodik – Prinzipien und Methoden zur Organisation theoretischer und praktischer Aktivitäten. Eine Reihe von Methoden, die in jeder Wissenschaft verwendet werden. Für SE werden wir Folgendes formulieren: Methodik sind die Prinzipien und Methoden zur Organisation der Aktivitäten eines Projektteams zur Erstellung eines Softwareprodukts. Softwareprodukt ist eine Lösung. Die Projektgruppe ist ein Team.

Einführung in die MSF-Methodik und historischer Hintergrund... Grundkonzepte der MSF-Methodik 1: MSF ist eine Softwareentwicklungsmethodik von Microsoft, die auf basiert praktische Erfahrung Unternehmen und beschreibt die Führung von Menschen und Prozessmanagement während der Entwicklung einer Lösung. 2: MSF besteht aus zwei Modellen und drei Disziplinen. Sie werden in fünf Dokumenten, sogenannten „White Papers“, detailliert beschrieben, die jeweils eine bestimmte Disziplin oder ein MSF-Modell abdecken.

Einführung in die MSF-Methodik und historischer Hintergrund... Grundkonzepte der MSF-Methodik MSF-Disziplinen und -Modelle: –MSF-Prozessmodell. –MSF-Projektteammodell. – MSF-Projektmanagementdisziplin. –MSF-Risikomanagementdisziplin. –MSF-Schulungsmanagementdisziplin. 3: Ärzte ohne Grenzen bietet mehrere an originelle Ideen, die wir später im Detail kennenlernen werden, aber vorerst listen wir sie einfach auf: – Einheitliche Vision des Projekts – Dreieck und Matrix der Kompromisse – Projektgruppe – ein Team von Gleichen – Risikomanagement –…

Einführung in die MSF-Methodik und historischer Hintergrund... Historischer Hintergrund 1993 – in dem Bemühen, die größtmögliche Wirkung von IT-Projekten zu erzielen, veröffentlichte Microsoft ein Paket von Richtlinien für den effektiven Entwurf, die Entwicklung, die Implementierung und die Wartung von auf seiner Grundlage erstellten Lösungen Technologien. Dieses Wissen basierte auf den Erfahrungen, die Microsoft bei der Arbeit an großen Projekten zur Softwareentwicklung und -wartung gesammelt hatte, auf der Erfahrung von Microsoft-Beratern und dem Besten, was die IT-Branche in diesem Jahr – MSF-Jahr – MSF-Jahr – MSF 4.0 – gesammelt hatte.

Einführung in die MSF-Methodik und historischer Hintergrund Informationsquellen – Die Hauptquelle sind natürlich Weißbücher (in momentan verfügbar für MSF 3.0). –Viele Informationen finden Sie auf der Microsoft-Website, darunter auch Abschnitte des TechNet-Portals (–Darüber hinaus können Interessierte autorisierte Kurse rund um MSF belegen. –Informationen zur neuesten Version von MSF 4.0:

Innovationen in MSF 4.0... Zwei Richtungen in MSF 4.0 – MSF für agile Softwareentwicklung – MSF für CMMI-Prozessverbesserung Wir erwägen MSF für agile Softwareentwicklung CMMI (Capability Maturity Model Integration) – eine wesentlich stärker formalisierte Methodik als agile Entwicklung, fokussiert zur Softwareentwicklung in großen Teams.

Was ist neu in MSF 4.0? Wichtige Punkte MSF für agile Softwareentwicklung bietet den einfachsten und flexibelsten Ansatz für den Entwicklungsprozess. Ein weiteres Beispiel für solche Methoden ist Extreme Programming (XP). Die agile Ausrichtung bei MSF konzentriert sich auf kleine Teams (5-6 Personen). Geht davon aus, dass Informationen über das zu entwickelnde Produkt nicht einfach während des Entwicklungsprozesses entdeckt werden, sondern sich im Laufe des Entwicklungsprozesses ändern können und werden. Daher sollte die erste funktionierende Version des Systems so früh wie möglich erstellt werden und das Produkt selbst tatsächlich aus Prototypen durch wiederholte Iterationen im Entwicklungszyklus entstehen.

Neuerungen in der Version MSF 4.0... Grundlegende Bestimmungen von MSF für die agile Softwareentwicklung Elemente der Methodik: -empfohlene Prozesse zur Erstellung von IT-Projekten; –Iterationsstruktur; -Rollen der Teammitglieder; –Dokumentvorlagen (Excel, Word); –Microsoft Project-Vorlagen; – Berichte; –Projektportal (SharePoint-Site-Vorlage). MSF für agile Softwareentwicklung konzentriert sich auf die Verwendung eines iterativen und evolutionären Modells des Entwicklungsprozesses und basiert auf Anwendungsszenarien.

Neuerungen in der Version MSF 4.0 Tool-Unterstützung für MSF 4.0 Im Gegensatz zu früheren Editionen Tool-Unterstützung in der Entwicklungsumgebung Microsoft Visual Studio 2005 Team System. Die Visual Studio 2005-Umgebung kann nun als integrierendes Tool fungieren, von dem aus Sie mit allen Tools arbeiten können, die die Phasen des Entwicklungsprozesses von der Erstellung von Projektplänen bis zur Durchführung unterstützen verschiedene Arten Testen, einschließlich Erstellen und Ausführen von Testskripten.

Teambildung. MSF-Projektteammodell für agile Softwareentwicklung... Grundprinzipien der Teambuilding-Methodik MSF ist davon überzeugt, dass die erfolgreiche Arbeit eines Teams an einem Projekt maßgeblich von seiner Struktur und der Verteilung der Verantwortlichkeiten der Rollengruppen abhängt. Die Teambildung bei Ärzte ohne Grenzen folgt einer Reihe von Schlüsselkonzepten, von denen einige offensichtlich erscheinen, andere mit Know-how vergleichbar sind.

Teambildung. MSF-Projektteammodell für agile Softwareentwicklung... Grundprinzipien der Teambildung Offensichtliche Konzepte (1): – Eine kundenorientierte Denkweise ist die Hauptpriorität jedes gut funktionierenden Projektteams. – Bedeutet ein zwingendes Verständnis der Geschäftsprobleme des Kunden und des Engagements des Teams, diese zu lösen. –Ebenso wichtig ist die aktive Beteiligung des Kunden an der Gestaltung der Lösung und die Einholung seines Feedbacks während des Entwicklungsprozesses.

Teambildung. MSF-Projektteammodell für agile Softwareentwicklung... Grundprinzipien der Teambildung Offensichtliche Konzepte (2): – Produktmentalität – jedes Mitglied des Projektteams sollte seine eigene Arbeit als unabhängiges Projekt oder als Beitrag zu einem größeren Projekt betrachten. –Die Einstellung zum Endprodukt bedeutet, dass dem Endergebnis des Projekts mehr Aufmerksamkeit geschenkt wird als dem Prozess, es zu erreichen. – Daraus folgt nicht, dass der Prozess selbst schlecht oder schlecht durchdacht sein könnte – er existiert lediglich, um ein Endziel zu erreichen, und nicht um seiner selbst willen.

Teambildung. MSF-Projektteammodell für agile Softwareentwicklung... Grundprinzipien der Teambildung Offensichtliche Konzepte (3): – Eine Null-Fehler-Denkweise ist das Streben nach höchster Qualität. Ziel des Teams ist es, seine Arbeit in höchstmöglicher Qualität auszuführen, idealerweise so, dass das Team, wenn es morgen aufgefordert wird, ein Ergebnis zu liefern, in der Lage ist, etwas zu liefern, das funktioniert. –In einem erfolgreichen Team fühlt sich jeder Mitarbeiter für die Qualität des Produkts verantwortlich. –Es kann nicht von einem Teammitglied an ein anderes oder von einer Rollengruppe an eine andere delegiert werden.

Teambildung. Projektteammodell MSF für agile Softwareentwicklung... Grundprinzipien des Teambuilding-Know-hows (1): – „Die Projektgruppe ist ein Team von Kollegen.“ Das Konzept bedeutet die gleichberechtigte Stellung aller Rollen im Team. –Um in einem gleichberechtigten Team erfolgreich zu sein, muss jedes seiner Mitglieder, unabhängig von seiner Rolle, für die Qualität des Produkts verantwortlich sein, die Interessen des Kunden verstehen und den Kern des zu lösenden Geschäftsproblems verstehen. -Gleichzeitig ist eine Entscheidung im Konsens zwischen den Rollen nicht dasselbe wie eine Entscheidung im Konsens zwischen den Mitarbeitern. –Jede Rollengruppe erfordert eine spezifische Organisationshierarchie, um die Arbeit zu verteilen und ihre Ressourcen zu verwalten.

Teambildung. MSF-Projektteammodell für agile Softwareentwicklung... Grundprinzipien des Teambuilding-Know-hows (2): – Lernbereitschaft ist ein Bekenntnis zur Idee der unermüdlichen Selbstentwicklung durch die Ansammlung von Erfahrungen und den Austausch von Wissen . –Es ermöglicht den Projektteammitgliedern, aus den negativen Erfahrungen gemachter Fehler zu lernen und Erfolge mithilfe der bewährten Methoden anderer zu wiederholen. – Am Ende der Hauptphasen des Projekts und am Ende des Gesamtprojekts werden offene Diskussionen über seinen Status und eine freundliche, aber sachliche Analyse erwartet.

Teambildung. MSF-Projektteammodell für agile Softwareentwicklung... Rollengruppen und Rollen Die MSF-Methodik basiert auf dem Postulat qualitativer Ziele, deren Erreichung den Erfolg des Projekts bestimmt. Diese Ziele bestimmen das Projektteammodell. Während das gesamte Team für den Erfolg des Projekts verantwortlich ist, ist jede seiner durch das Modell definierten Rollengruppen mit einem der Ziele verbunden und arbeitet daran, dieses zu erreichen.

Teambildung. MSF-Projektteammodell für agile Softwareentwicklung... Rollengruppen und Rollen Rollengruppen (Cluster) – Programmmanagement – ​​Produktarchitektur – Entwicklung – Tests – Release-Vorgänge – Zufriedenheit der Benutzererfahrung – Produktmanagement

Teambildung. Projektteammodell MSF für agile Softwareentwicklung... Rollengruppen und Rollen Rollen: – Projektmanager – Rollengruppe Programmmanagement – ​​Architekt (archrect) – Rollengruppe Architektur – Entwickler (developer) – Rollengruppe Entwicklung – Tester – Rollengruppe Testing – Release Manager – Rollengruppe Release Management – ​​Business Analyst – Rollengruppen Produktmanagement und Kundenzufriedenheit

Microsoft hat verschiedene Techniken vorbereitet und wendet diese an, um nicht nur die lebensrettenden Systeme abzudecken, sondern auch die technologische Infrastruktur, die sie unterstützt.

Im Kontext der Betrachtung des Lebenszyklusprozesses interessieren wir uns für die Entwicklungsmethodik: sowohl für einen der Hauptaspekte des Managements und der Interaktion zwischen den Prozessbeteiligten als auch für andere Wissensbereiche (Risikomanagement, Planung). Im Allgemeinen werden die von MSF abgedeckten Disziplinen in fünf Teilen (den sogenannten White Books) beschrieben. Interessant ist jedoch, dass Microsoft-Beraterteams in der Praxis nicht diese Ressource nutzen, sondern die MSF-Methodik für agile Softwareentwicklung, die eine ist angewandte Version von MSF und spiegelt das Allgemeine wider methodischer Ansatz zur iterativen Entwicklung.

Wenn wir uns direkt dem Entwicklungs- und Implementierungsprozess zuwenden, ist dieser gekennzeichnet durch:

• Iterativität;
• daraus resultierende Bildung einer IT-Lösung.

Eine IT-Lösung ist die koordinierte Bereitstellung einer Reihe von Elementen (z. B. Software und Hardware, Dokumentation, Schulung, Support und externe Kommunikation), die zur Erfüllung der Geschäftsanforderungen eines bestimmten Kunden erforderlich sind.

Es sind IT-Lösungen (und nicht nur Softwareprodukte, die in Form von Distributionen geliefert werden), die laut MSF das Hauptprodukt und Ergebnis des Entwicklungs- und Implementierungsprozesses sind (obwohl vielen Methoden eine ähnliche Philosophie zugrunde liegt, der Begriff „Softwareprodukt“) ” ist immer noch sehr verbreitet).

Die Kernzusammensetzung von MSF besteht aus zwei Modellen und drei Disziplinen, die in fünf Weißbüchern ausführlich erörtert werden. MSF umfasst:

• Modelle:
  • - Gruppenmodell,
  • - Prozessmodell;
• Disziplinen:
• - Disziplin „Projektmanagement“,
• - Disziplin „Risikomanagement“,
• - Disziplin „Readiness Management“.

Prozessmodell. Das Prozessmodell ist das „Rückgrat“ der MSF-Methodik. Das MSF-Prozessmodell basiert auf einer Kombination des Wasserfall- und Spiralmodells des IS-Lebenszyklus. Somit wird in der MSF-Methodik das Projekt in Etappen umgesetzt, alle Etappen können „spiralförmig“ wiederholt werden und zwischen den Etappen gibt es vorgegebene Kontrollpunkte (Abb. 7.20).

Das Modell kombiniert die Vorhersagbarkeit und die umfassenden Planungsmöglichkeiten des Wasserfallmodells mit dem variablen Ansatz zur Problemlösung, der Spiralmodellen innewohnt. Das Ergebnis ist ein hohes Maß an Vorhersagbarkeit™, das aktuelle Bedingungen und Umgebungen berücksichtigt und auf unternehmensweiter Ebene funktioniert.

Erstellen eines Gesamtbildes der IT-Lösung. Die erste Stufe des MSF-Modells ist Das Das große Ganze schaffen IT-Lösungen. Aufgaben Bühne Sind:

• das Projektteam bestimmen;
• die Projektstruktur festlegen;
• Bestimmen Sie die Geschäftsziele des Projekts.
• die aktuelle Situation einschätzen;
• Erstellen Sie ein Dokument, das das Gesamtbild und den Umfang des Projekts beschreibt.
• Benutzeranforderungen ermitteln;
• Konzepte für IT-Lösungen entwickeln;
• Risiken einschätzen;
• Schließe die Bühne.

Reis. 7.20.

Die Etappe enthält zwei Kontrollpunkte: „Das Rückgrat des Teams ist gebildet“Und„Das Gesamtbild der IT-Lösung ist entstanden.“

Der erste Kontrollpunkt beschränkt sich nicht darauf, eine vollständige Liste der Projektteilnehmer namentlich zu erhalten. Um diesen Meilenstein zu erreichen, müssen die Rollen und Verantwortlichkeiten der Teammitglieder sowie Hierarchien für Verantwortung und Berichterstattung definiert werden. Auch dieser Kontrollpunkt geht davon aus allgemeine Struktur Teams und etablierte Kanäle der Interaktion mit dem Kunden.

Kontrollpunkt " Das Gesamtbild der IT-Lösung ist entstanden“ Dabei geht es darum, ein Konzept für eine IT-Lösung zu entwickeln, das das Team in Zukunft dabei unterstützt, die im Projekt erklärten Geschäftsziele zu erreichen. Ein Meilenstein zeichnet sich durch eine Beschreibung dessen aus, was im Projekt enthalten ist und was nicht. In diesem Fall ist das Dokument nicht endgültig: Zu diesem Zeitpunkt wird eine vorläufige, von Experten begutachtete Version erstellt.

Der Abschluss der Etappe erfolgt, wenn der dritte Kontrollpunkt erreicht wird – „Das Dokument zum Gesamtbild und Umfang des Projekts wurde genehmigt.“

Planung. In der Planungsphase muss das Team verstehen, wie das Produkt und seine Implementierung aussehen werden. In dieser Phase wird eine funktionale Spezifikation erstellt, der Arbeitsplan detailliert beschrieben und der Budget- und Zeitaufwand für die Umsetzung des Projekts bewertet.

Während der Planungsphase wird auch eine Bedarfsanalyse durchgeführt. Die MSF-Methodik unterteilt Anforderungen in vier Typen: Geschäftsanforderungen, Benutzeranforderungen, funktionale Anforderungen und System Anforderungen. Anschließend beginnt das Team mit dem Entwurf der Lösung und der Planung von Benutzerprofilen. Basierend auf den ausgewählten Profilen werden Anwendungsszenarien entwickelt, die von gleichartigen Benutzern ausgeführt werden. Darüber hinaus werden alternative Einsatzmöglichkeiten des Systems berücksichtigt.

Planungsziele können wie folgt formuliert werden:

• eine IT-Lösungsarchitektur entwickeln;
• eine funktionale Spezifikation erstellen;
• Projektpläne entwickeln;
• einen Arbeitsplan erstellen;
• eine Entwicklungs-, Test- und Testbetriebsumgebung erstellen;
• Schließe die Bühne.

Die Planung ist eine ziemlich komplexe und umfangreiche Phase mit fünf Kontrollpunkten:

• das Pflichtenheft wurde erstellt;
• ein Risikomanagementplan wurde erstellt;
• die Entwicklungs- und Testumgebung ist definiert;
• der Projektplan und der Zeitplan wurden erstellt;
• Projektpläne wurden genehmigt.

Alle Ergebnisse dieser Phase werden anschließend für Kompromissentscheidungen genutzt.

Entwicklung. Die Entwicklungsphase umfasst die direkte Erstellung einer IT-Lösung, d. h. Schreiben und Dokumentieren von Programmcode. Nachdem sichergestellt wurde, dass die Aufgaben der vorherigen Phasen abgeschlossen sind, beginnt das Projektteam mit der Umsetzung der für die Entwicklungsphase charakteristischen Aufgaben:

• einen Prototyp einer IT-Lösung erstellen;
• Softwarekomponenten einer IT-Lösung entwickeln;
• eine fertige IT-Lösung erstellen (betrachtet als eine Folge von Zwischenversionen);
• Schließen Sie die Entwicklung ab (implementieren Sie alle Funktionen in der IT-Lösung, liefern Sie den Code und die Dokumentation an den Kunden).

Die MSF-Methodik identifiziert die folgenden Entwicklungsergebnisse:

• Quellprogrammcode und ausführbare Dateien;
• Installationsskripte und Konfigurationen für die Bereitstellung;
• endgültige funktionale Spezifikation;
• Elemente zur Unterstützung von IT-Lösungen;
• Spezifikationen und Testszenarien.

Die Entwicklungsphase enthält auch Kontrollpunkte, von denen der wichtigste ist „Endgültige Genehmigung des Projektumfangs.“ Dieser Meilenstein gilt als erreicht, wenn alle Produktfunktionen implementiert sind und die Vortests bestanden haben. Es wird davon ausgegangen, dass die IT-Lösung danach für externe Tests geeignet ist und die Stabilisierung beginnt.

Stabilisierung. Bühne Stabilisierung erforderlich, um das Produkt auf das erforderliche Qualitätsniveau zu bringen. Zur Stabilisierung gehört die Durchführung umfassender Tests zur Erkennung und Beseitigung von Mängeln. Darüber hinaus werden im Rahmen der Stabilisierungsphase Einsatzszenarien getestet und ein Probebetrieb der IT-Aufbewahrung durchgeführt.

Das Testen beinhaltet die folgenden Typen Aktivitäten:

• Komponententests;
• Datenbanktests;
• Prüfung der IT-Infrastruktur;
• Sicherheitstests;
• Integrationstests;
• ergonomische Tests;
• Belastbarkeitstest;
• Regressionstests;
• Berichterstattung über Tests.

Die nächste Aufgabe ist der Probebetrieb. Hierzu werden IT-Lösungen an Arbeitsplätzen zum Betrieb durch eine Gruppe von Testern auf Kundenseite bereitgestellt, die anschließend direkt mit der IT-Lösung arbeiten. Es ist wichtig, die Funktionsfähigkeit der IT-Lösung in realen Betriebsszenarien zu testen.

Der wichtigste Kontrollpunkt ist „ Das Erscheinen einer Version der IT-Lösung, in der keine kritischen Fehler gefunden wurden.“ Danach werden mehrere endgültige Versionen veröffentlicht, von denen eine als die erfolgreichste anerkannt wird und im Testbetrieb eingesetzt wird. Der letzte Kontrollpunkt für diese Etappe ist „ Bestätigung der Produktbereitschaft für den Einsatz im industriellen Umfeld.“

Einsatz. Die Bereitstellungsphase umfasst die Installation der IT-Lösung, die industrielle Stabilisierung und die endgültige Übergabe an den Kunden und das Support-Team. Hauptkontrollpunkte der Etappe:

• Hauptkomponenten im Einsatz;
• die Lösung wird bereitgestellt;
• die Lösung ist stabilisiert;
• Die Lösung wurde dem Kunden zum Betrieb übergeben.

Es ist wichtig zu verstehen, dass es sehr schwierig ist, den formellen Abschluss der Bereitstellungsphase festzustellen. Der Grund liegt darin, dass Probleme auch im industriellen Betrieb erkannt werden können. Daher ist eine klare Definition der Bedingungen für das Erreichen des letzten Meilensteins in jedem einzelnen Projekt erforderlich.

Gruppenmodell. Das Management von Projektteams ist ein wichtiger Bestandteil von MSF. Die Methodik umfasst ein detailliertes Gruppenmodell. Das Teammodell entstand als Reaktion auf die Notwendigkeit eines klaren Verständnisses der Rollen, Verantwortlichkeiten und Aufgaben jedes Mitglieds des Projektteams (Tabelle 7.12). Es wird angenommen, dass dieses Modell dazu beiträgt, Mitarbeiter zu motivieren, ihre Arbeit zu vereinfachen und ihre Effizienz zu steigern.

Tisch 7.12

Rollen, Ziele und Funktionsbereiche von MSF

		Funktionsbereiche
Produkt Management	Bieten Sie der Lösung einen geschäftlichen Mehrwert. Definieren Sie die Lösung innerhalb der Projektbeschränkungen. Stellen Sie die Einhaltung sicher	Kommunikation. Analytik. Planung
Programm-Management	Setzen Sie das Projekt innerhalb der Vorgaben um. Implementieren Sie die Mittel, mit denen Anforderungen erfüllt werden	Projektmanagement. Programm-Management. Resourcenmanagement. Durchsetzung. Qualitätskontrolle. Projektbetrieb
Entwicklung	Erstellen Sie eine IT-Lösung gemäß den Spezifikationen	Entwicklung von IT-Lösungen. Technologieberatung
Testen	Überprüfen Sie die Konformität der IT-Lösung mit den vorgegebenen Qualitätsbedingungen. Genehmigen Sie die Freigabe der IT-Lösung	Alle Arten von Tests
Freigabe und Betrieb	Stellen Sie die IT-Lösung bereit und stellen Sie den Übergang zur Produktion sicher. Stellen Sie sicher, dass die Bedürfnisse und Erwartungen der Geschäftsbereiche des Kunden erfüllt werden	Release-Management. Infrastruktur. Operationen. Build-Management. Werkzeugverwaltung
	Optimieren Sie die Benutzerfreundlichkeit der IT-Lösung. Stellen Sie sicher, dass die Benutzer bereit sind, mit der IT-Lösung zu arbeiten. Stellen Sie sicher, dass die Anforderungen und Erwartungen der Benutzer erfüllt werden	Spezielle Fähigkeiten. Interaktion mit dem Support-Service. Ausbildung. Benutzerfreundlichkeit. UI-Design

Für große Projekte mit großen Implementierungsteams können zusätzliche Fokusgruppen und Funktionsgruppen erstellt werden, und MSF bietet sogar eine Rollenkompatibilitätstabelle an, die zeigt, welche Rollen akzeptabel, unerwünscht oder überhaupt nicht kompatibel sind (Tabelle 7.13).

Es ist wichtig zu verstehen, dass einige Rollen nicht von einer Person ausgeführt werden sollten. Wenn beispielsweise die Verantwortung für Produktmanagement und Programmmanagement einer Person zugewiesen wird, kann dies zu einem Interessenkonflikt führen, da der Projektmanager wichtige Prozesse in den Bereichen Kosten, Zeitplan, Teamkommunikation, Risiken usw. steuern und nicht das Geschäft bestimmen muss Prioritäten. Es gibt auch eine Rolle, deren Kombination mit anderen im Allgemeinen nicht empfohlen wird – die Rolle des Entwicklers, die auf der Annahme ausgeübt wurde, dass seine Aktivitäten im Projekt am kritischsten sind und jede Zuweisung zusätzlicher Verantwortlichkeiten an Entwickler zu Störungen führen würde des Projektzeitplans.

Tisch 7.13

Optionen zum Kombinieren von Rollen in MSF

	Kontrolle Produkte	Kontrolle Programm	Entwicklung	Testen	und Ausbeutung	Benutzerinteraktion
Produkt Management
Programm-Management
Entwicklung
Testen
Freigabe und Betrieb
Benutzerinteraktion

Im Gegensatz zu vielen anderen Unternehmensmethoden gelten die von MSF definierten Meilensteine, die Zusammensetzung des Projektteams, die Vorbilder und andere Elemente daher nicht nur für Microsoft-Lösungen. Dies bedeutet, dass MSF ein flexiblerer und universellerer Ansatz für die Implementierung anderer Systeme oder Softwareprodukte ist.

Am Ziel. Methodik zur Umsetzung von Lösungen Am Ziel wurde von Navision für die Implementierung seiner Softwareprodukte entwickelt. Nach der Übernahme von Navision durch Microsoft wurde beschlossen, On Target fertigzustellen, das zu diesem Zeitpunkt Vorlagen für Beschreibungen von Geschäftsprozessen, Dokumentation, IT-Organisationsstrukturen und Qualifikationsanforderungen für Spezialisten enthielt (Tabelle 7.14).

Tabelle 7.14

Phasen der On Target-Methodik

		Aktionen
Design	Generieren Sie nichtfunktionale Anforderungen für Informationssysteme. Formulieren Sie Grundsätze zur Umsetzung von Anforderungen	Gestaltung der Umsetzung funktionaler Anforderungen im IS. Beschreibung der Schnittstellen und Modifikationen. Klärung des Plans und Budgets
Entwicklung und Tests	Entwickeln Sie einen I.S.-Test und einen I.S.	Entwicklung und Prüfung der Funktionalität. Entwicklung und Test von Schnittstellen. Entwicklung von Modifikationen und Ergänzungen
Einsatz	Stellen Sie das System im Unternehmen des Kunden bereit	Bereitstellung an Arbeitsplätzen. Rechte und Zugriffsebenen einrichten. Überprüfung der Ausgangsdaten und Vorgänge. Datentransfer. Schulung und Erstellung von Unterweisungen für Arbeitsplätze
Ausbeutung	Nehmen Sie den IS in Betrieb. Führen Sie die Lieferung und Annahme des IP durch	Inbetriebnahme des IS. Probebetrieb des IS. Übergabe und Abnahme des IP

Aufgrund der Tatsache, dass Microsoft zum Zeitpunkt der Übernahme von Navision bereits seine bewährten Unternehmensmethoden MSF und MOF angewendet hatte, wurde On Target anschließend ergänzt und bis zur Markteinführung daraus Microsoft Dynamics der Verbesserungen, MS Dynamics Sure Step/Microsoft Business Solutions Partner Methodology.

Microsoft Business Solutions Partner-Methodik.MBS-Partnermethodik - Dies ist eine Weiterentwicklung von On Target. Diese Methodik zielt nicht nur darauf ab, geistiges Eigentum zu schaffen, sondern auch die Kundenzufriedenheit zu maximieren.

Reis. 7.21.

Wie in Abb. zu sehen ist. 7.21 unterscheiden sich die Etappen nicht wesentlich von denen in On Target. Auf der Bühne Diagnose Es wird eine Analyse und Beschreibung der Geschäftsprozesse des Kundenunternehmens durchgeführt und wichtige Geschäftsanforderungen identifiziert. Es erfolgt eine erste Festlegung des Budgets, des Zeitplans, der Grenzen und der Ergebnisse des Projekts. Es wird eine Arbeitsgruppe gebildet, in der die Mitarbeiter des Kunden bei der Diagnose des Unternehmens behilflich sind. Am Ende der Phase werden Berichte über die durchgeführten Diagnosen erstellt, Projektbeschränkungen erfasst und Vorschläge für die Entwicklung und Implementierung des IS dokumentiert.

Die Rollen im Projekt sind in Abb. dargestellt. 7.22.

Reis. 7.22.

Auf der Bühne Analyse Der Lenkungsausschuss und die Projektgruppe werden schließlich gebildet. Es werden Dokumente wie der Projektplan, die Projektcharta und das Berichtsverfahren erstellt und die Bedingungen für die Abnahme sowie das Änderungs- und Risikomanagement festgelegt. Durch Schulungen werden die Mitarbeiter des Kunden mit der Grundfunktionalität des Produkts vertraut gemacht. IS-Anforderungen werden geklärt und detailliert, was zur Bildung einer funktionalen Anforderungsspezifikation führt. Die ersten Schnittstellenmöglichkeiten werden geschaffen und das Unternehmen beginnt, sich auf Veränderungen in den Geschäftsprozessen vorzubereiten.

Auf der Bühne Design Basierend auf den technischen Spezifikationen wird ein Softwaredesign erstellt, das die Funktionalität des IS, Schnittstellen zu externen IS, das Verfahren für Test, Entwicklung und Abnahme beschreibt. In dieser Phase wird auch die Qualitätskontrollplanung durchgeführt, der Zeitplan und die Ressourcen des Projekts werden festgelegt.

Anschließend beginnt die Etappe Entwicklung und Tests. Ganz am Anfang der Phase werden die Entwicklungsumgebung, die Testumgebung und die Integrationsumgebung eingerichtet. Die erste Implementierung von Funktionen und Schnittstellen wird durchgeführt und sofort getestet. Anschließend werden die Entwicklungsergebnisse an den Kunden übergeben, der auch Tests durchführt. Fehler werden korrigiert und der Kunde passt die Anforderungen an. Weiterentwicklungen und Tests werden wiederholt. Abschließend erfolgt die umfassende Prüfung des IP beim Kunden vor Ort.

Es erfolgt die abschließende Erkennung von Fehlern und Anforderungsänderungen. Alle Entwicklungsergebnisse werden dann in einer einzigen Arbeitsumgebung zusammengefasst. Das System wird konfiguriert und Daten werden dorthin übertragen. Den Abschluss der Etappe bilden die Abschlusstests und der Beginn der Vorbereitung auf die Abnahme.

Einsatz beginnt mit der offiziellen Übergabe des Projekts an den Kunden. Der Kunde bewertet die Erreichung der Projektziele anhand zuvor definierter Erfolgskriterien. Als nächstes beginnt die Vorbereitung des Systems für den kommerziellen Betrieb. Es werden Endbenutzerschulungen angeboten. Die Erstbetreuung erfolgt durch die Spezialisten des Auftragnehmers. Am Ende der Phase wird das Projekt offiziell abgeschlossen und vom Kunden bewertet.

Und endlich kommt die Bühne Erste Unterstützung. Es erfolgt eine regelmäßige (und sogar tägliche) Unterstützung der Arbeit des Kunden mit dem IS. Das System wird regelmäßig aktualisiert und Fehler werden in neuen Versionen behoben. Änderungen der Kundenanforderungen werden überwacht. Die Planung neuer Projekte kann beginnen.

Andrey Kolesov

Die Rezension wurde auf der Grundlage der in vorgestellten Materialien erstellt Trainingskurs zur Vorbereitung auf die Prüfung im Rahmen des Microsoft Certified Solution Developer N 70-300-Zertifizierungsprogramms: Analysieren von Anforderungen und Definieren von Microsoft .NET-Lösungsarchitekturen. Die russische Übersetzung dieses Kurses wurde 2004 vom Verlag Russian Edition unter dem Titel „Anforderungsanalyse und Erstellung einer Lösungsarchitektur auf Basis von Microsoft .NET“ veröffentlicht.

IN letzten Jahren Wir sehen, dass führende Lieferanten Entwicklungswerkzeuge Software (hauptsächlich IBM Rational und Borland) geht von der Veröffentlichung einzelner Tools zur Schaffung umfassender Application Lifecycle Management (ALM)-Plattformen über. Microsoft (http://www.microsoft.com) hat den Prozess der Erstellung einer vollständigen Palette von ALM-Lösungen zur Automatisierung verschiedener Phasen der Softwareproduktion noch nicht beschleunigt, bewegt sich jedoch in diese Richtung (dies wird durch Folgendes belegt). Letzte Neuigkeiten von der TechEd 2004-Konferenz, siehe Seitenleiste), und der Schwerpunkt liegt auf Design- und Entwicklungstools - Visio, Visual Studio usw.

Um die ALM-Ideologie in die Praxis umzusetzen, ist jedoch nicht nur ein Werkzeugsatz an sich erforderlich, sondern auch ein allgemeiner Ansatz methodische Grundlage. Microsoft entwickelt seit mehr als zehn Jahren seine eigene ALM-Methodik namens Microsoft Solutions Framework (MSF). Es mag überraschend erscheinen, aber MSF als Ganzes ist im Wesentlichen eine plattformunabhängige Methodik, die einzelne Prozesse detailliert auf der Abstraktionsebene beschreibt. Microsoft-eigene Tools sind darin nur in minimalem Umfang vorhanden, lediglich als Beispiele für die Umsetzung bestimmter Empfehlungen. Gleichzeitig bringt dieses Konzept, wenn auch implizit, die allgemeine Ausrichtung der Entwicklungsinstrumente des Unternehmens (das Aufgabenspektrum, für das sie bestimmt sind) deutlich zum Ausdruck, was aus der Analyse der Dynamik seiner Entwicklung sehr deutlich hervorgeht. Während sich MSF vor zehn Jahren auf die Erstellung lokaler Clientanwendungen konzentrierte, konzentriert es sich heute auf die Entwicklung und Implementierung komplexer Systeme im Unternehmensmaßstab.

MSF-Prozessstruktur

Wenn wir über Lebenszyklus-Prozessmodelle für Softwareentwicklungsprojekte sprechen, müssen wir zunächst zwei Hauptschemata erwähnen: Wasserfall und Spirale (Abb. 1), die zwei unterschiedliche Ansätze zur Organisation dieser Arbeit widerspiegeln.

Das Wasserfallmodell sieht einen klaren Übergang von Stufe zu Stufe vor: Die Arbeit der nächsten Stufe beginnt erst, nachdem alle Aufgaben der vorherigen Stufe erledigt sind. Dieser Stil eignet sich für Projekte, bei denen die Projektanforderungen im Vorfeld klar definiert sind und später wahrscheinlich nicht angepasst werden. Dieses Entwicklungsorganisationsschema ist aus Sicht des Projektmanagements sehr praktisch, da es Ihnen ermöglicht, die Zusammensetzung und Verantwortlichkeiten seiner Teilnehmer klar zu formulieren und den Projektzeitplan zu steuern.

Das Spiralmodell konzentriert sich in der Regel auf den Extremfall, bei dem die Anforderungen und Parameter des Projekts kontinuierlich angepasst werden und neue Anforderungen nur dann formuliert werden, wenn spezifische Arbeiten erforderlich sind. Dieses Muster wird oft mit dem Konzept der „extremen Entwicklung“ in Verbindung gebracht; Gleichzeitig arbeiten Auftragnehmer und Auftraggeber ständig eng zusammen, der Auftraggeber ist in jeder Phase involviert und formuliert seine Gedanken zu den erstellten Bauteilen. Allerdings besteht bei einer solchen Organisation ein sehr hohes Risiko, dass der Entwicklungsprozess außer Kontrolle gerät, sodass dieses Modell in der Realität nur in relativ kleinen Projekten eingesetzt wird.

Das Problem besteht jedoch darin, dass es in den meisten Fällen praktisch unmöglich ist, alle Anforderungen für eine Aufgabe im Voraus zu ermitteln und selbst die formulierten Anforderungen einer Korrektur unterliegen. Dann gilt es jedoch, die Projektmanagementfähigkeit zu erhöhen, ohne die die Erstellung komplexer Software schlicht unmöglich ist. Den Kompromiss zwischen diesen widersprüchlichen Anforderungen bietet das MSF-Prozessmodell, das Wasserfall- und Spiralentwicklungsmodelle kombiniert: Das Projekt wird stufenweise umgesetzt, wobei entsprechende Kontrollpunkte vorhanden sind, und die Abfolge der Stufen selbst kann spiralförmig wiederholt werden ( Abb. 2).

In diesem Fall werden die meilensteinbasierte Planung und Vorhersehbarkeit des Wasserfallmodells durch das Kundenfeedback und den kreativen Ansatz zur Problemlösung ergänzt, die für das Spiralmodell charakteristisch sind. Somit ermöglicht Ihnen das MSF-Prozessmodell die Erstellung und Bereitstellung von Lösungen auf Unternehmensebene, wodurch der Projektfortschritt vorhersehbar ist und die realen Bedingungen ihrer Implementierung berücksichtigt werden.

Erstellen eines Gesamtbildes der Anwendung

In dieser Phase werden folgende Hauptaufgaben gelöst:

• Festlegung der Zusammensetzung des Teams;
• Definition der Projektstruktur;
• Geschäftsziele definieren;
• Einschätzung der aktuellen Situation;
• Erstellen eines Dokuments über das Gesamtbild und den Umfang des Projekts;
• Definition von Anforderungen und Benutzerprofilen;
• Entwicklung eines Lösungskonzeptes;
• Risikobewertung;
• Abschluss der Bühne.

In dieser Phase werden zwei Zwischenkontrollpunkte identifiziert: „Der Kern des Teams ist organisiert“ und „Das Gesamtbild der Lösung ist erstellt.“

Der Kern des Teams ist organisiert. Dies erfordert nicht unbedingt eine vollständige Liste der Teamnamen, aber das Projektstrukturdokument sollte die Rollen und Verantwortlichkeiten jedes Teammitglieds definieren sowie die Berichts- und Verantwortungshierarchie innerhalb der Gruppe, die Interaktionskanäle mit dem Kunden usw. beschreiben die Gesamtstruktur des Teams.

Es wurde ein Gesamtbild der Lösung erstellt. Dabei geht es darum, ein Lösungskonzept zu entwickeln, das das Team dabei unterstützen soll, die langfristigen Geschäftsziele des Projekts zu erreichen. Der Projektumfang definiert, was im Projektkontext enthalten ist und was außerhalb des Projektumfangs liegt. Zu diesem Zeitpunkt sprechen wir über die Erstellung der ersten Version des Dokuments, die sich in der Phase der Überprüfung durch Teammitglieder und der Genehmigung durch den Kunden befindet.

Die Phase endet mit dem Kontrollpunkt „Genehmigung des Dokuments zum Gesamtbild und Umfang des Projekts“.

Planung

Während der Planungsphase entscheidet das Team, was entwickelt werden muss und erstellt Pläne zur Umsetzung des Produkts. Es wird eine funktionale Spezifikation erstellt, ein Lösungsentwurf erstellt, Arbeitspläne detailliert beschrieben und die Kosten und der Zeitplan für die Erzielung von Ergebnissen bewertet.

In dieser Phase erfolgt eine Anforderungsanalyse, die in Geschäftsanforderungen, Benutzeranforderungen, Funktionsanforderungen und Systemanforderungen unterteilt wird. Nach dem Sammeln und Analysieren der Anforderungen des Teams wird ein Lösungsentwurf entwickelt, Benutzerprofile definiert, anschließend Szenarien für die Verwendung der Lösung erstellt, von Benutzern desselben Typs ausgeführt und anschließend Anwendungsfälle für das System festgelegt.

Die Phase besteht aus drei Phasen: konzeptionelles, logisches und physisches Design. Auf der Bühne konzeptionell Die Entwurfsaufgabe wird aus Sicht der Benutzer- und Geschäftsanforderungen betrachtet und endet mit der Definition einer Reihe von Szenarien für die Nutzung des Systems. Bei logisch Beim Design wird das Problem aus der Sicht des Projektteams betrachtet, die Lösung wird in Form einer Reihe von Dienstleistungen dargestellt. Und schon auf der Bühne körperlich Die Entwurfsaufgabe wird aus Sicht der Programmierer betrachtet, die eingesetzten Technologien und Softwareschnittstellen werden spezifiziert.

In dieser Phase werden folgende Aufgaben gelöst:

• Entwicklung der Projekt- und Lösungsarchitektur;
• Erstellen einer funktionalen Spezifikation;
• Entwicklung von Projektplänen;
• Entwicklung eines Kalenderplans;
• Schaffung einer Entwicklungs-, Test- und Pilotumgebung;
• Abschluss der Bühne.

Meilensteine ​​der Planungsphase sind mit dem Erreichen der folgenden Ergebnisse verbunden:

• funktionale Spezifikation;
• Risikomanagementplan;
• Definieren der Entwicklungs- und Testumgebung;
• Masterplan und Projektzeitplan.

Die Ergebnisse dieser Phase dienen dazu, in der Zukunft Kompromissentscheidungen zu treffen.

Entwicklung

In der Entwicklungsphase wird eine Lösung erstellt, einschließlich des Schreibens und Dokumentierens von Code. Zu Beginn dieser Phase überprüft das Team die Erledigung aller für die vorherigen Phasen charakteristischen Aufgaben und beginnt dann mit der Lösung der folgenden Aufgaben:

• Erstellen eines Anwendungsprototyps;
• Entwicklung von Anwendungssoftwarekomponenten;
• Erstellen einer Lösung (eine Abfolge täglicher oder häufigerer Anwendungsbuilds);
• Abschluss der Entwicklung (Implementierung aller Funktionen, Lieferung von Code und Dokumentation).

Die Ergebnisse der Phase umfassen die folgenden Elemente:

• Quellcode und ausführbare Dateien;
• Installationsskripte und Konfigurationen für die Bereitstellung;
• endgültige funktionale Spezifikation;
• Entscheidungsunterstützungselemente;
• Spezifikationen und Testszenarien.

Der wichtigste Meilenstein der Phase ist die „endgültige Genehmigung des Projektumfangs“. Zu diesem Zeitpunkt sind alle Produktfunktionen fertig und wurden innerhalb ihres Moduls getestet. Danach ist das Produkt für die externe Prüfung und Stabilisierung bereit. Darüber hinaus können Kunden, Benutzer, Supportmitarbeiter und wichtige Projektbeteiligte eine Vorschau des Produkts anzeigen und etwaige Mängel identifizieren, die vor der Auslieferung behoben werden müssen.

Stabilisierung

In dieser Phase wird die Veröffentlichung der endgültigen Version des Produkts vorbereitet und auf ein bestimmtes Qualitätsniveau gebracht. Hier werden eine Reihe von Testarbeiten durchgeführt (Erkennung und Beseitigung von Mängeln), das Produkteinsatzszenario überprüft und ein Pilotbetrieb durchgeführt.

Das Testen umfasst die folgenden Hauptarbeitsarten:

• Komponententests;
• Datenbanktests;
• Infrastrukturtests;
• Sicherheitstests;
• Integrationstests;
• Analyse der Benutzerfreundlichkeit des Produkts;
• Lasttests (einschließlich Ressourcenverbrauch und Leistungsanalyse);
• Regressionstests;
• Berichterstattung über Tests.

Wenn die Lösung ausreichend stabil ist, wird sie in einer Testumgebung unter Einbeziehung der Benutzer und unter Verwendung realer Arbeitsszenarien getestet.

Einer der Hauptindikatoren der Stabilisierungsphase ist die Anzahl der erkannten Fehler. Die Annäherung dieses Wertes an einen stetigen Rückgang ist ein Zeichen dafür, dass die Arbeiten am Produkt bald abgeschlossen sind. Der wichtigste Zwischenkontrollpunkt ist das Erscheinen einer Version, in der durch die Bemühungen des Projektteams selbst kein einziger Fehler entdeckt wurde. Darauf folgen Veröffentlichungen von Produktkandidaten für ihre Forschung unter Pilotbetriebsbedingungen. Der letzte Kontrollpunkt ist die Bestätigung, dass das Produkt zur Veröffentlichung und vollständigen Bereitstellung in einer industriellen Umgebung bereit ist.

Einsatz

In dieser Phase werden die Lösung und die notwendigen Umgebungskomponenten installiert, in einer industriellen Umgebung stabilisiert und das Projekt an das Support-Team übergeben. Darüber hinaus wird das Gesamtprojekt hinsichtlich der Kundenzufriedenheit analysiert. Die wichtigsten Kontrollpunkte dieser Phase sind:

• Hauptkomponenten im Einsatz;
• die Lösung als Ganzes wird bereitgestellt;
• die eingesetzte Lösung wird stabilisiert;
• Die Lösung wird vom Kunden bereitgestellt und in Betrieb genommen.

Es sollte betont werden, dass es recht schwierig sein kann, den Zeitpunkt des Abschlusses dieser Phase formal zu bestimmen, da die Identifizierung von Problemen während des industriellen Betriebs fortgesetzt werden kann. Aus diesem Grund ist es wichtig, die Kriterien für den letzten Prüfpunkt der Bereitstellungsphase klar zu definieren und nicht zu versuchen, alles zu debuggen.

Kommentare zu den Arbeitsschritten

Lassen Sie uns dem oben Gesagten noch einige wichtige Anmerkungen hinzufügen. Im Allgemeinen liegen allen modernen Methoden der industriellen Softwareentwicklung (IBM/Rational, Borland, Microsoft usw.) dieselben Ideen zugrunde. Und das ist nicht verwunderlich: Gerade das unterscheidet bewährte Technologien von der handwerklichen Produktion. Gleichzeitig verfolgt jedoch jede Methodik ihren eigenen Ansatz zur Hervorhebung der verschiedenen Entwicklungsstadien und verwendet oft ihre eigene Terminologie, was es schwierig macht, Parallelen zwischen ihnen zu ziehen. Dieses Problem wird durch das Fehlen einer etablierten russischen Terminologie verschärft.

Die heute allgemein akzeptierte Liste der ALM-Stufen, an die sich insbesondere Borland und Rational halten, lautet wie folgt:

• Definieren (Anforderungen definieren);
• Design (Analyse und Design);
• Entwickeln (Entwicklung);
• Test, Test);
• Bereitstellen

Wie leicht zu erkennen ist, bietet das MSF-Modell eine etwas andere Aufteilung der Stufen und ihrer Namen. Ich möchte die Leser darauf aufmerksam machen, dass es sich hier nicht einfach um unterschiedliche Bezeichnungen für die gleichen Arten von Aktivitäten handelt. Das objektive Problem der Kategorisierung besteht darin, dass die Identifizierung unabhängiger Phasen im Anwendungslebenszyklus sehr willkürlich ist, insbesondere wenn es um ein iteratives zyklisches Entwicklungsmodell geht. Beispielsweise verwischt der weit verbreitete Einsatz visueller Designmethoden mit automatischer Codegenerierung effektiv die Grenze zwischen Design und Codierung. Und das Testen durchdringt im Allgemeinen die gesamte Lebensdauer eines Programms.

Es gibt auch subjektive Faktoren, die durch Unterschiede in den strategischen Geschäftszielen verschiedener Methodenanbieter bestimmt werden. Genau aus diesem Grund schenkt Microsoft, dessen Kerngeschäft nicht Entwicklungstools, sondern Plattformsoftware sind, (im Vergleich zu Rational und Borland) den allgemeinen Fragen der Organisation des Prozesses der Anwendungserstellung sowie deren Implementierung mehr Aufmerksamkeit.

Daher umfasst die Envisioning-Phase beispielsweise die Festlegung nicht nur der Softwareanforderungen, sondern auch der Zusammensetzung des Teams (sie enthält insbesondere sehr interessante Empfehlungen zum Rollenmodell des Entwicklungsteams sowie mögliche Optionen für die Kombination von Rollen). . Und die Stabilisierungsphase beinhaltet nicht nur das Testen selbst, sondern auch den tatsächlichen Testbetrieb der Software, bei dem die anfänglichen Anforderungen des Kunden geklärt werden können. Was können wir über den besonderen Schwerpunkt von Microsoft auf die Aufgaben der Bereitstellung von Lösungen sagen?

Microsoft für Entwickler – Neuigkeiten von TechEd“2004 Auf der Microsoft TechEd 2004-Konferenz Ende Mai in San Diego, Kalifornien, USA, wurden eine Reihe wichtiger Ankündigungen zur Entwicklung von Entwicklungstools, neuen Initiativen im Bereich der Informationssystemsicherheit und der Lebenszyklusunterstützung für Microsoft-Produkte gemacht. Auf der Konferenz wurden zwei neue Tools vorgestellt, die für die Integration konzipiert sind aktuelle Version Visual Studio .NET 2003. Die erste davon, Web Services Enhancements 2.0 (WSE 2.0), ermöglicht es Ihnen, das Sicherheitsniveau der erstellten Webdienste zu erhöhen, indem Sie die neuesten WS-Security-Protokollspezifikationen verwenden (basierend auf den OASIS-Standards, die in genehmigt wurden). 2004), einschließlich WS-Policy, WS-Security Policy, WS-Trust und WS-SecurityConversation. WSE 2.0 für VS.NET ist jetzt verfügbar. Darüber hinaus plant Microsoft, diese Technologie zur Lösung von Daten- und Anwendungsintegrationsproblemen einzusetzen: Ein spezielles Modul, BizTalk Server Adapter für WSE 2.0, ist derzeit nur als vorläufige technische Version verfügbar. Das zweite Tool, das Microsoft Office Information Bridge Framework (IBF), jetzt in der Betaversion, ermöglicht die Verwendung von Microsoft Office als intelligente Clientanwendungen bei der Arbeit mit Webdiensten, die mit WSE 2.0 erstellt wurden. IBF ist ein Satz mehrerer Komponenten, die für Entwickler und Benutzer gedacht sind. Einer davon wird auf der Office 2003 Pro-Seite installiert und ermöglicht die Interaktion mit IBF-Anwendungen direkt aus Office-Dokumenten über Smarttags. Die zweite IBF-Komponente ist der Information Bridge Metadata Designer, der eine Verbindung zur VS.NET-Umgebung herstellt und die visuelle Entwicklung von Webdiensten mithilfe des WSE 2.0-Sicherheitsmodells ermöglicht. IBF umfasst außerdem den Information Bridge Metadata Service – ein Server-Softwaremodul, mit dem Sie Daten von laufenden Geschäftsanwendungen über Webdienste an Client-Software übertragen können. Die vielleicht interessanteste Information für Entwickler ist jedoch die Absicht, die Fähigkeit zur Verwaltung des gesamten Anwendungslebenszyklus in VS.NET deutlich zu erweitern. Die auf der TechEd 2004 vorgestellte Version von Visual Studio 2005 (Codename Whidbey) Enterprise Edition hieß Visual Studio Team System (VSTS). Es wird davon ausgegangen, dass dieses System in drei Hauptversionen geliefert wird: Team Architect, Team Developer und Team Test. Entworfen für Architekten Softwarelösungen Das Team Architect-Tool umfasst drei Designer zum Entwerfen verteilter Anwendungen, zum Modellieren logischer Infrastruktur und zum automatischen Generieren von Code. Der letzte (Klassendesigner) führt eine bidirektionale Synchronisierung zwischen dem visuellen Modell des Projekts und dem Programmcode durch. Bemerkenswert ist, dass nicht die klassische UML, sondern Microsofts eigene Modellierungssprache Notification verwendet wird. Visual Studio wird weiterhin Visio zur Unterstützung von UML verwenden, aber die integrierten Tools in VS selbst bewegen sich in eine etwas andere Richtung. Team Developer umfasst eine Reihe von Tools, die eine statische Analyse und Profilierung des Programmcodes durchführen, den Grad der Codeabdeckung während des Tests bestimmen und eine Reihe anderer Probleme lösen. Diese Tools können direkt in der Anwendungsentwicklungsumgebung verwendet werden, was die Effizienz des Debugging-Prozesses erheblich verbessert. Es ist zu beachten, dass Team Architect eine Weiterentwicklung der bereits in der aktuellen Version von VS 2003 verfügbaren Tools ist. Die Funktionalität von Team Developer wird von der aktuellen Version von VS.NET 2003 nur geringfügig abgedeckt, um solche Probleme heute effektiv zu lösen Es ist notwendig, die entsprechenden Erweiterungen für VS von Drittanbietern anzubinden. Aber in VS 2005 können Entwickler die integrierten Tools von Microsoft verwenden. Was die dritte Komponente von VSTS – Team Test – betrifft, die für Lasttests von Anwendungen entwickelt wurde, war diese Funktionalität bisher nur in eigenständigen Produkten anderer Anbieter verfügbar. Jetzt ist es direkt in der VS 2005-Umgebung erschienen und wird von Microsoft ausgeführt. Dabei Besondere Aufmerksamkeit wird sich den Aufgaben des Testens von Webdiensten widmen, einschließlich der Verwendung von Skripten, die mit verschiedenen Transportprotokollen und Fernüberwachungsmodi arbeiten. Aus all diesen Informationen geht hervor, dass Microsoft die Fähigkeiten seiner Tools zur Erstellung komplexer Systeme auf Unternehmensebene erweitert, einschließlich Tools zur automatisierten Unterstützung aller Phasen des Anwendungslebenszyklus und die schrittweise Verdrängung entsprechender Erweiterungen von Drittanbietern. Viele unabhängige Anbieter begrüßten die Ankündigungen jedoch, da die VSTS-Innovationen die Zusammenarbeit innerhalb des „VS-Partner-Ökosystems“, das mehrere Dutzend Entwicklungsunternehmen umfasst, auf eine völlig neue Ebene heben werden. Insbesondere Borland, Compuware, Telelogic AB und Unisys haben bereits auf der TechEd 2004 ihre Unterstützung für das zukünftige Produkt angekündigt.

Bildung von Projektteams

Eines der Schlüsselelemente der Projektumsetzung ist die Aufgabe, das Team seiner Teilnehmer zu leiten. Daher hat MSF neben dem Prozessmodell ein detailliertes Teammodell (MSF-Teammodell) entwickelt, das auf der Bedeutung eines klaren Verständnisses der Rollen, Verantwortlichkeiten und Aufgaben der einzelnen Mitglieder sowie deren erhöhter Verantwortung dafür basiert die Umsetzung des Gesamtprojektes. Es kann je nach Bedarf und Kontext des Projekts, der Größe des Teams und der Erfahrung der Teammitglieder angewendet werden. Die im MSF-Teammodell verwendeten Rollen werden im Folgenden kurz beschrieben.

Produktmanager(Produktmanager) ist für die Verwaltung der Beziehungen zum Kunden verantwortlich. In der Entwurfsphase erfasst er die Anforderungen des Kunden und stellt sicher, dass diese den Anforderungen seines Unternehmens entsprechen. Außerdem entwickelt er einen Plan für die Kommunikation mit dem Kunden während des Projekts, einschließlich der Organisation von Kundentreffen, Produktvorführungen und anderen Marketingaktivitäten.

Progamm Manager(Programmmanager) leitet die eigentliche Softwareentwicklung und ist für deren Lieferung gemäß genehmigter Spezifikationen verantwortlich.

Entwickler(Entwickler) beschäftigt sich mit der Softwareentwicklung nach vorgegebenen Spezifikationen.

Prüfer(Tester) identifiziert und behebt alle Probleme im Produkt und erteilt die endgültige Freigabe für die Veröffentlichung. Außerdem wird die Übereinstimmung der im Produkt implementierten Funktionen mit dem Gesamtkonzept und -umfang des Projekts bewertet.

Release-Manager(Release Manager) ist für die Bereitstellung und den Support des Produkts verantwortlich und überprüft die Korrektheit der IT-Infrastruktur des Kunden, um sicherzustellen, dass diese für den Betrieb der Software bereit ist.

Usability-Spezialist(User-Experience-Spezialist) untersucht und löst Benutzerprobleme und bewertet das Produkt im Hinblick auf die Erfüllung ihrer Bedürfnisse.

Natürlich müssen in einem kleinen Projekt einzelne Teammitglieder mehrere Rollen unter einen Hut bringen. Dabei sind je nach Qualifikation und Erfahrung der Mitarbeiter sowie den Besonderheiten des Projekts unterschiedliche Möglichkeiten möglich, dennoch müssen bestimmte Regeln zur „Kompatibilität“ der Rollen beachtet werden (siehe Tabelle). Beachten Sie beispielsweise, dass dem Entwickler nicht empfohlen wird, andere Rollen auszuüben.

Mögliche Rollenkombination im Projektteam

	Produktmanager	Progamm Manager	Entwickler	Prüfer	Release-Manager	Usability-Spezialist
Produktmanager		-	-	+	-+	-+
Progamm Manager	-		-	-+	+	-+
Entwickler	-	-		-	-	-
Prüfer	+	-+	-		+	+
Release-Manager	-+	+	-	+		-+
Usability-Spezialist	+	-+	-	+	-+
Notiz: " - " - Kombination wird nicht empfohlen, " -+ „ – unerwünscht“, + " - Vielleicht.

Neben den Projektdurchführenden selbst können dem Team weitere Personen angehören:

• der Initiator oder Sponsor des Projekts, der in der Regel auch über die Genehmigung des Projekts entscheidet;
• Kunde (Geschäftssponsor) – derjenige, der geschäftliche Vorteile aus dem Projekt erhält;
• Benutzer – eine Gruppe von Personen, die direkt mit der Lösung arbeiten;
• Lösungssupport-Team, das für die Wartung nach der Bereitstellung verantwortlich ist.

Kompromisse managen

Eines der Hauptprobleme jedes Projekts sind mögliche Terminverstöße oder Budgetüberschreitungen. Der Hauptgrund dafür ist der unklare Umfang des Projekts, der bestimmt, welche Probleme das Produkt lösen soll und welche nicht in seiner Kompetenz liegen. Deshalb für effektives Management Das Projekt erfordert Folgendes:

• Bestimmen Sie die dem Projekt auferlegten Einschränkungen.
• Trade-Off-Management organisieren;
• Change Management organisieren;
• stellen die Projektüberwachung sicher.

Beim Umgang mit Kompromissen geht es darum, ein Gleichgewicht aller Komponenten des Projekts zu erreichen, wenn das Team erkennt, dass es nicht möglich sein wird, alle zugewiesenen Aufgaben in der vorgegebenen Zeit zu lösen. Das Projektteam und der Kunde müssen die Kompromisse ständig analysieren und auf die schwierige Wahl zwischen der Erweiterung des Projektbudgets (einschließlich der Nichteinhaltung von Fristen) und der Vollständigkeit seiner Funktionalität vorbereitet sein.

Wie Sie wissen, besteht in jedem Projekt ein ganz klarer Zusammenhang zwischen Parametern wie Ressourcen, Zeitplan und Funktionsumfang (Abb. 3). Jede Änderung einer der Komponenten erfordert eine Anpassung der anderen. Deshalb das Versprechen gelungene Kreation Produkt, das den Kundenanforderungen entspricht - Ermittlung und Sicherstellung der optimalen Balance zwischen Ressourcen, Liefertermin und Funktionalität.

Um diese schwierigen Probleme zu lösen, verwendet man am besten eine Kompromissmatrix, in der alle aufgeführten Komponenten in obligatorische, wünschenswerte und optionale Komponenten unterteilt werden (letztere können ausgeschlossen oder auf die nächste Version verschoben werden). Die Funktionsweise der Kompromissmatrix können Sie anhand der folgenden Phrasenvorlage demonstrieren:

Da ____________ erfasst ist, ermitteln wir _____________ und passen ggf. ____________________ an.

Durch das Einfügen von Variablen aus einer vorgegebenen Kompromissmatrix ist es möglich, eine Formulierung zu erhalten, die dem Projektziel entspricht, zum Beispiel:

Da die RESSOURCEN feststehen, legen wir den ZEITPLAN fest und passen gegebenenfalls die FUNKTIONALITÄT an.

Abschließend stellen wir fest, dass es ein weiteres wichtiges Merkmal des Projekts gibt – die Qualität. Aber genau dieser Indikator sollte unbedingt fixiert werden. Bei der Entwicklung von Softwareprodukten sollte man das Dreieck der Kompromisse niemals in ein Tetraeder verwandeln.

Russische Version von Visual Basic .NET Im Gegensatz zu Microsoft-Produkten großer Nachfrage (Windows, Office), die in mehrere Dutzend übersetzt werden Landessprachen Derzeit gibt es für die Visual Studio .NET-Entwicklungstools nur acht lokalisierte Versionen (Französisch, Deutsch, Spanisch, Italienisch, Japanisch, Koreanisch und zwei chinesische Versionen). Die Beherrschung der russischen Sprache begann erst in diesem Jahr mit einem Tool, das jedoch am weitesten verbreitet war: Visual Basic .NET Standard Edition (die Auslieferung begann im Mai 2004). Um sich die Bedeutung dieses Projekts vorzustellen, müssen Sie bedenken, dass der gesamte Lokalisierungsumfang von VS.NET 2003 etwa 20 Millionen Wörter beträgt (einschließlich des gesamten Hilfesystems), was deutlich größer ist als der des gesamten Microsoft Office 2003-Pakets VB.NET Standard ist eine Teilmenge von VS.NET, sein Lokalisierungsvolumen beträgt 5,6 Millionen Wörter. Anzumerken ist, dass die Standard-Edition bei professionellen Entwicklern noch nicht sehr gefragt ist. Dennoch wird das Vorhandensein russischer Dokumentation laut Mitarbeitern der Moskauer Repräsentanz von Microsoft sicherlich das Interesse der Entwickler an VB.NET Standard steigern, zumal trotz der eingeschränkten Funktionen im Vergleich zur VS.NET Pro-Version dieses Tool verwendet wird Sie können ein sehr breites Spektrum an Anwendungen, Komponenten und Webdiensten in Industriequalität erstellen. Im Gegensatz zu VS.NET Pro kann VB.NET Standard keine Windows- und Web-Steuerelemente, mobilen Anwendungen oder leistungsstarke Serverlösungen erstellen. Natürlich enthält VB.NET keine anderen Programmiersprachen – VC++, VC# und VJ#. Wir möchten jedoch betonen, dass VS.NET Pro mehr als 1000 US-Dollar kostet (Upgrade-Option 550 US-Dollar) und VB.NET Standard nur 100 US-Dollar kostet. Und doch ist die Entstehung des russischen VB.NET vor allem mit der Absicht von Microsoft verbunden, seine Tools aktiv einem breiteren Kreis von Programmierern zugänglich zu machen, vor allem im Bereich der Bildung, insbesondere der Entwicklerschulung. Was die Aussichten für eine Erweiterung des Angebots an russischsprachigen Entwicklungstools angeht, äußern Microsoft-Mitarbeiter diese eher vorsichtig. Allerdings ist die Wahrscheinlichkeit, dass eine russische Version des zukünftigen VS 2005 erscheint, recht hoch.

Einführung

MSF-Struktur

Projektteammodell

Rollencluster

Prozessmodell

Meilensteine ​​und Phasen

Iterativer Ansatz

Konzeptentwicklungsphase (Envisioning)

Planungsphase

Entwicklungsphase

Stabilisierungsphase

Bereitstellungsphase

Disziplin des Projektmanagements

Disziplin des Risikomanagements

Schulungsmanagementdisziplin

Neue Versionen von MSF

Literatur

Projektteams skalieren

Rollenkompatibilitätstabelle

Einführung

Microsoft Solutions Framework, im Folgenden MSF , repräsentiert den Ansatz des Unternehmens Microsoft bis zum IT-Management -Projekte. Diese Überprüfung konzentriert sich auf Version 3.0 dieser Methodik, die im Juni 2002 veröffentlicht wurde.

MSF-Struktur

MSF-Technologie besteht aus zwei Modellen:

Projektteammodell;

Prozessmodell.

Und drei Disziplinen:

Disziplin im Projektmanagement;

Disziplin des Risikomanagements;

Managementdisziplin trainieren.

Alle werden in Abschnitt 5 ausführlicher beschrieben weiße Papiere . Schauen wir uns alle diese Teile genauer an.

Projektteammodell

MSF-Methodik Wir haben uns vom traditionellen Ansatz entfernt, Projektgruppen in Form einer Pyramiden- und Hierarchiestruktur aufzubauen, sie in Rollencluster aufzuteilen und die Ziele und Kompetenzbereiche jedes Clusters klar zu definieren.

Zu den Grundprinzipien und Kernkonzepten, die das MSF-Projektteam definieren, gehören:

Ein Team von Teamkollegen oder Rollengleichheit in einem Team. Jedes Teammitglied muss für die Qualität des Produkts verantwortlich sein, die Interessen des Kunden berücksichtigen und den Kern des zu lösenden Geschäftsproblems verstehen. Aber es gibt keine Gleichberechtigung unter den Arbeitnehmern, d.h. Jeder Rollencluster verfügt über eine eigene Organisationshierarchie zur Arbeitsverteilung und Ressourcenverwaltung.

Einheitliche Vision des Projekts. Nämlich ein einziges klares Verständnis der Ziele und Zielsetzungen des Projekts.

Verteilung der Verantwortlichkeiten bei der Erfassung von Berichten.

Konzentrieren Sie sich auf das vom Kunden gewünschte Endergebnis;

Mitarbeiter verfügen über die notwendigen Befugnisse;

Offene Kommunikation;

Einstellung für keine Mängel;

Verpflichtung zur Verbesserung;

Flexibilität und Bereitschaft zur Veränderung;

Interesse und Begeisterung.

Rollencluster

Ärzte ohne Grenzen basiert auf dem Postulat von sechs qualitativen Zielen, deren Erreichung über den Erfolg des Projekts entscheidet. Diese Ziele bestimmen das Projektteammodell. Während das gesamte Team für den Erfolg des Projekts verantwortlich ist, ist jedes seiner durch das Modell definierten Rollencluster mit einem der sechs genannten Ziele verbunden und arbeitet auf dessen Erreichung hin.

Das MSF-Projektteammodell definiert sechs Rollencluster. Sie sind für unterschiedliche Kompetenzbereiche zuständig ( Funktionsbereiche ) und damit verbundene Ziele und Zielsetzungen. Manchmal werden Rollencluster einfach Rollen genannt. Eine Rolle (oder ein Cluster) kann durch einen oder mehrere Mitarbeiter repräsentiert werden, abhängig von der Größe des Projekts, seiner Komplexität und den erforderlichen Fachkenntnissen zur Umsetzung aller Kompetenzbereiche des Clusters.

Produkt Management

Ziel: Zufriedene Kunden.

Fachgebiet:

Marketing;

Geschäftsrendite (Geschäftsprioritäten);

Vertretung der Interessen des Kunden;

Produktplanung.

Programm-Management

Ziel: Ergebnisse innerhalb der Designvorgaben erzielen.

Fachgebiet:

Projektmanagement;

Entwicklung einer Lösungsarchitektur;

Kontrolle des Produktionsprozesses;

Verwaltungsdienstleistungen.

Entwicklung

Ziel: Erstellen eines Produkts gemäß Spezifikation.

Fachgebiet:

Technologieberatung;

Design und Umsetzung;

Anwendungsentwicklung;

Entwicklung der Infrastruktur.

Testen

Ziel: Freigabe zur Produktfreigabe erst nach Feststellung und Behebung aller Mängel.

Fachgebiet:

Testplanung;

Testentwicklung;

Testberichte.

Kundenzufriedenheit

Ziel: Verbesserung der Benutzereffizienz, Steigerung des Verbraucherwerts des Produkts.

Fachgebiet:

Bereitstellung technischer Unterstützung;

Ausbildung;

Ergonomie;

Grafikdesign;

Internationalisierung;

Allgemeine Barrierefreiheit (Sicherstellung der Arbeitsfähigkeit für Benutzer mit Behinderungen);

Release-Management

Ziel: Nahtlose Implementierung und Wartung des Produkts.

Fachgebiet:

Infrastruktur;

Begleiten;

Arbeitsprozesse;

Verwaltung der Freigabe des fertigen Produkts.

Die MSF-Grundsätze prägen dies Projektmanagement-Ansatz, in welchem:

Die Verantwortung für das Projektmanagement wird auf die Leiter von Rollenclustern innerhalb des Teams verteilt – jedes Mitglied des Projektteams ist für den Gesamterfolg des Projekts und die Qualität des erstellten Produkts verantwortlich.

Professionelle Manager fungieren als Berater und Mentoren für das Team, anstatt Kontrollfunktionen über das Team auszuüben – in einem effektiven Team verfügt jedes Teammitglied über die nötige Autorität, um seine Aufgaben zu erfüllen, und ist zuversichtlich, dass es von seinen Kollegen alles erhält, was es braucht.

Wie aus dem oben Gesagten hervorgeht, ist eines der charakteristischen Merkmale von MSF das Fehlen einer Projektmanagerstelle!

Skalierung des Projektteammodells

ProjektteammodellÄrzte ohne Grenzen bietet die Aufteilung großer Teams (mehr als 10 Personen) in kleine multidisziplinäre Bereichsgruppen ( Feature-Teams ). Diese kleinen Teams arbeiten parallel und synchronisieren ihre Bemühungen regelmäßig.

In einem Rollencluster können sich viele Personen befinden;

Eine Person kann mehrere Rollen übernehmen;

Große Teams:

• Gruppen von Richtungen erstellen;

  Funktionsgruppen erstellen;

Kleine Teams:

• Schauen Sie sich die Rollenkompatibilitätstabelle an (aus der Tabelle können wir schließen, dass die Mindestteamgröße 3 Personen beträgt: Kundenzufriedenheit, Produktmanagement, Tests; Programm- und Release-Management; Entwicklung);

Prozessmodell

Das MSF-Prozessmodell stellt die allgemeine Methodik für die Entwicklung und Implementierung von IT-Lösungen dar, nämlich die Abfolge von Aktionen, die während der Implementierung des Projekts durchgeführt werden.

Das MSF-Prozessmodell kombiniert die Prinzipien des Kaskaden- und Spiralmodells.

Die drei Merkmale des MSF-Prozessmodells sind:

Phasen- und meilensteinbasierter Ansatz.

Iterativer Ansatz.

Meilensteine ​​und Phasen

Im Mittelpunkt der MSF-Methodik stehen Meilensteine, die als Bezugspunkte für die Planung und Überwachung des Projektfortschritts dienen.

Ärzte ohne Grenzen führt zwei Arten von Meilensteinen ein: Haupt- und Zwischenmeilensteine. Sie verfügen über folgende Merkmale:

Wichtige Meilensteine ​​dienen als Übergangspunkte von einer Phase zur anderen. Sie ermitteln auch Änderungen in den aktuellen Aufgaben von Rollenclustern.

Meilensteine ​​zeigen den während eines Projekts erzielten Fortschritt an und unterteilen große Arbeitsabschnitte in kleinere, überschaubare Bereiche.

Zwischenmeilensteine ​​können von Projekt zu Projekt variieren. Ärzte ohne Grenzen empfiehlt die Verwendung eines bestimmten Satzes von Meilensteinen, aber in der Praxis kann das Projektteam diese entsprechend den Besonderheiten seiner Arbeit festlegen.

Iterativer Ansatz

Ein iterativer Ansatz für den Entwicklungsprozess ist bei MSF weit verbreitet. MSF empfiehlt, dass Sie mit der Entwicklung einer Lösung beginnen, indem Sie deren Kernfunktionalität erstellen, testen und implementieren. Und dann kommen immer mehr neue Features zur Lösung hinzu.

Phasen und Meilensteine ​​des MSF-Prozessmodells

Das MSF-Prozessmodell deckt den Prozess der Lösungserstellung von der Konzeption bis zur endgültigen Implementierung ab. Jede Phase endet mit einem großen Meilenstein, dessen Ergebnisse auch außerhalb des Projektteams sichtbar werden.

Für jede Phase des Prozessmodells MSF definiert:

Was (welche Artefakte) ist das Ergebnis dieser Phase?

Woran jeder Rollencluster in dieser Phase arbeitet;

Konzeptentwicklungsphase (Envisioning)

Die Hauptaufgaben der Konzeptentwicklungsphase bestehen darin, den Kern des Projektteams zu bilden und ein Visions-/Umfangsdokument zu erstellen.

Meilenstein: Konzept genehmigt.

Ergebnisse:

allgemeine Beschreibung und Projektrahmen (Vision/Scope-Dokument).

Dokument zur Risikobewertung.

Beschreibung des Projektstrukturdokuments.

Der Kern des Projektteams wurde gebildet

Ein Entwurf des Projektkonzepts wurde erstellt

Planungsphase

In der Planungsphase wird der Großteil der Arbeit zur Erstellung von Projektplänen erledigt. Dazu gehört, dass das Designteam funktionale Spezifikationen erstellt, Designs entwickelt, Arbeitspläne erstellt, Projektkosten und Entwicklungszeitpläne für verschiedene Projektkomponenten schätzt.

Meilenstein: Projektpläne wurden genehmigt.

Ergebnisse:

Funktionale Spezifikation;

Risikomanagementplan;

Masterplan und Masterplan des Projekts.

Technologieüberprüfung;

Die Grundversion des Pflichtenheftes ist erstellt;

Eine Basisversion des Masterprojektplans wurde erstellt;

Eine Basisversion des Projektzusammenfassungsplans wurde erstellt;

Es werden Entwicklungs- und Testumgebungen bereitgestellt.

Entwicklungsphase

Während der Entwicklungsphase konzentriert sich das Projektteam auf die Erstellung der Komponenten der Lösung (einschließlich Dokumentation und Programmcode). Es ist zu beachten, dass sich die Aktivität des Projektteams in dieser Phase nicht auf das Schreiben von Code durch die Entwickler beschränkt – alle Rollencluster beteiligen sich aktiv an der Erstellung und dem Testen der Lösung.

Meilenstein: Entwicklung abgeschlossen.

Ergebnisse:

Installations- und Konfigurationsskripte;

Endgültige funktionale Spezifikation;

Materialien zur Lösungsunterstützung;

Spezifikationen und Testskripte.

Konzept bestätigt;

Bau 1 abgeschlossen;

Bau 2 abgeschlossen;

Build n ist abgeschlossen.

Stabilisierungsphase

Während der Stabilisierungsphase wird die entwickelte Lösung getestet. Gleichzeitig liegt der Fokus auf dem Betrieb in einem realitätsnahen Modell der Produktionsumgebung. Das Projektteam ist für die Priorisierung und Behebung von Fehlern sowie die Vorbereitung der Lösung für die Veröffentlichung verantwortlich.

Meilenstein: Lösungsbereitschaft genehmigt

Ergebnisse:

Endprodukt (Golden Release);

Versionshinweise;

Materialien zur Lösungsunterstützung;

Testergebnisse und Tools;

Quell- und ausführbarer Anwendungscode;

Projektdokumentation;

Analyse der abgeschlossenen Phase (Meilensteinüberprüfung).

Konvergenzpunkt (An einem Fehlerkonvergenzpunkt macht sich ein erheblicher Fortschritt bei der Beseitigung von Fehlern bemerkbar, d Ende.

Null Punkte ( Der Zero-Bug-Bounce-Point ist der Zeitpunkt, an dem zum ersten Mal alle identifizierten Fehler beseitigt werden.)

Versionskandidaten

Benchmark-Test abgeschlossen

Verbraucherakzeptanztest abgeschlossen

Pilotimplementierung abgeschlossen

Bereitstellungsphase

In dieser Phase implementiert das Projektteam die Technologien und Lösungskomponenten, stabilisiert die implementierte Lösung, delegiert die Arbeit an die Supportmitarbeiter und holt die endgültige Genehmigung der Projektergebnisse vom Kunden ein.

Meilenstein: Die Umsetzung ist abgeschlossen.

Ergebnisse:

Informationssysteme Betrieb und Support;

Verfahren und Prozesse;

Wissensdatenbanken, Berichte, Protokollprotokolle (Logbücher);

Versionen von Projektdokumenten, Datensätzen (Lastsätzen) und Programmcode, die während des Projekts entwickelt wurden;

Projektabschlussbericht;

Endgültige Versionen aller Projektdokumente;

Indikatoren zur Kunden- und Verbraucherzufriedenheit;

Beschreibung der nächsten Schritte.

Schlüsselkomponenten im Einsatz;

Feldimplementierung abgeschlossen;

Die implementierte Lösung wurde stabilisiert.

Was sonst noch im Prozessmodell abgedeckt wird

Am Rande wird das Konfigurationsmanagement erwähnt ( Protokollierung und Überwachung der Zustände von Projektelementen), Change Management und Risikomanagement. Es wird gesagt, dass man sie nicht vergessen darf, und es werden mehrere Optionen mit einer oberflächlichen Beschreibung angegeben, wie dies getan werden kann;

Es werden viele Definitionen gegeben.

Disziplin des Projektmanagements

Träger professioneller Managementkompetenzen und Organisator der Teamarbeit bei MSF ist das Rollencluster „Programmmanagement“. Typische Führungsaufgaben sind jedoch auf die Leiter aller Rollencluster der Projektgruppe verteilt.

Diese Disziplin liefert keine konkreten Rezepte für das Projektmanagement und enthält keine Erläuterungen zu den zahlreichen Arbeitsmethoden erfahrener Manager. Es zeigt jedoch, wie die PrinzipienÄrzte ohne Grenzen einen Ansatz für das Projektmanagement entwickeln, bei dem:

Die Verantwortung für das Projektmanagement wird auf die Leiter der Rollencluster innerhalb des Teams verteilt.

Professionelle Manager fungieren als Berater und Mentoren des Teams und nicht in Aufsichtsfunktion.

Verteilung der Projektmanagementaufgaben unter den Teamleitern

Für Teamleiter und den Rollencluster „Programmmanagement“ ist der WBS ein Projektmanagement-Tool, das die Erstellung von Plänen und Zeitplänen erleichtert. Ein Projektstrukturplan (WBS) ist eine Strukturierung der Arbeit eines Projekts, die seine wichtigsten Ergebnisse widerspiegelt und seinen Umfang definiert. Arbeiten, die nicht im WBS beschrieben sind, liegen außerhalb des Projektumfangs. Bei MSF ist die Erstellung eines WBS eine Teamarbeit, an der alle Rollencluster beteiligt sind. Jede Rolle ist für die Bereitstellung einer detaillierten Beschreibung verantwortlich eigene Arbeit.

Disziplin des Risikomanagements

Die Risikomanagement-Disziplin von MSF orientiert sich am bekannten kontinuierlichen Risikomanagement-Prozessmodell des Software Engineering Institute (SEI). Darüber hinaus erfolgt die Interpretation dieses Modells im Kontext der Erfahrungen von Microsoft. Diese Disziplin bietet Grundsätze, Ideen und Empfehlungen, unterstützt durch einen sechsstufigen Prozess für ein erfolgreiches aktives Risikomanagement. Dieser Prozess umfasst:

Risiko-Einschätzung– Dies ist eine Phase, in der die Mitglieder des Projektteams die Fakten zu Risiken dem gesamten Team zur Diskussion vorlegen können.

Risikoanalyse– Dies ist die Phase, in der die im vorherigen Schritt gesammelten Schätzungen und Daten in eine Form umgewandelt werden, die eine Risikopriorisierung ermöglicht. Risikopriorisierung ermöglicht es dem Projektteam, die wichtigsten davon zu verwalten und die dafür erforderlichen Ressourcen bereitzustellen.

Risikoplanung wird auf der Grundlage der in der Analysephase gewonnenen Informationen durchgeführt und zielt auf die Entwicklung von Strategien, Plänen und konkreten Schritten ab.

Risikoüberwachung durchgeführt, um spezifische Risiken und Fortschritte bei der Umsetzung von Plänen zu überwachen.

Korrektur der Situation (Risikokontrolle) stellt den Prozess der Umsetzung von Plänen dar, die in Bezug auf Risiken angenommen wurden, und die Überwachung des Fortschritts ihrer Umsetzung.

Risikolernen formalisiert den Prozess der Assimilation der während der Projektarbeit gesammelten Erfahrungen in einer Form, die sowohl innerhalb des Projektteams als auch auf der Ebene des gesamten Unternehmens nutzbar ist.

Managementdisziplin Vorbereitung

Diese Disziplin widmet sich dem Management von Wissen, beruflichen Fähigkeiten und Fertigkeiten, die für die Planung, Erstellung und Aufrechterhaltung erfolgreicher Lösungen erforderlich sind. Die MSF-Trainingsmanagement-Disziplin bietet Anleitungen für einen proaktiven Ansatz für das Wissensmanagement im gesamten Lebenszyklus Informationstechnologien. Dieser Prozess besteht aus vier Schritten:

Definition

Projektszenarien ( Szenarien).

Benötigte Qualifikationen(Kompetenzen).

Professionelle Fähigkeiten(Kenntnisse).

Bewertung

Messung von Wissen, Fertigkeiten, Fähigkeiten ( M Kenntnisse, Fähigkeiten, Fertigkeiten vermitteln).

Nichtkonformitätsanalyse ( Lücken analysieren).

Erstellung eines Lehrplans ( Lernpläne erstellen).

Einstellung

Ausbildung.

Überwachung des Fortschritts (Fortschritt verfolgen).

Verständnis

Analyse der Ergebnisse(Überprüfungsergebnisse).

Wissensmanagement(Wissen verwalten).

Neue Versionen von MSF

Eine neue Version MSF 4.0 wurde 2005 eingeführt. In dieser Version wurde die Methodik in zwei Bereiche unterteilt: MSF für agile Softwareentwicklung und MSF für CMMI-Prozessverbesserung. MSF für agile Softwareentwicklung spiegelt in gewisser Weise die jüngsten Trends wider, die mit der Entstehung von Methoden verbunden sind, die den einfachsten und flexibelsten Ansatz für den Entwicklungsprozess bieten. MSF für CMMI Process Improvement ist ein strenger, dokumentierter Prozess, der für große Teams und einen langen Entwicklungsprozess konzipiert ist und mehr Überprüfung, mehr Planung, Genehmigungsverfahren, Nachverfolgung der ausgegebenen Ressourcen usw. umfasst. Diese Version sieht aus wie eine leichte Version von 3.0 und konzentriert sich auf Produkte Microsoft , nämlich Visual Studio 2005 Team System und MS-Projekt.

Oleg Bolschakow

Die Softwareentwicklungsmethodik Microsoft Solution Framework erschien 1994. Die MSF-Methodik basiert auf der gesammelten Managementerfahrung von Microsoft durch menschliche Ressourcen und Arbeitsabläufe bei der Entwicklung von Softwarelösungen. Dieses Wissen basiert auf der Erfahrung von Microsoft bei der Arbeit an großen Softwareentwicklungs- und Wartungsprojekten sowie auf anderen Erfahrungen in der IT-Branche.

Die Methodik basiert auf Modellen und Disziplinen.

• Projektteammodell;
• Prozessmodell.

Disziplinen:

• Projektmanagementdisziplin;
• Risikomanagementdisziplin;
• Managementdisziplin trainieren.

Im Kontext des Themas dieses Artikels werden wir keine Disziplinen betrachten, sondern uns auf die Anwendung des Projektteammodells durch kleine Entwicklungsteams konzentrieren.

Das MSF-Teammodell beschreibt den Ansatz von Microsoft zur Organisation von Projektpersonal und -aktivitäten, um den Projekterfolg zu maximieren. Dieses Modell definiert Rollencluster, ihre Kompetenz- und Verantwortungsbereiche sowie Empfehlungen für Projektteammitglieder, damit sie ihre Mission, das Projekt zum Leben zu erwecken, erfolgreich erfüllen können. Gemäß dem MSF-Modell sind Projektteams als kleine multidisziplinäre Teams strukturiert, deren Mitglieder sich die Verantwortung teilen und sich in ihren Fachgebieten gegenseitig ergänzen. Dies ermöglicht eine klare Fokussierung auf die Bedürfnisse des Projekts. Das Projektteam eint eine gemeinsame Vision des Projekts, der Wunsch, es zum Leben zu erwecken, hohe Ansprüche an die Qualität der Arbeit und der Wunsch, sich selbst zu verbessern.

Die Projektgruppe umfasst folgende Rollencluster (Abb. 1):

• Produkt Management. Das zentrale Ziel dieses Rollenclusters sind zufriedene Kunden. Ein Projekt kann nicht als erfolgreich betrachtet werden, wenn es die Bedürfnisse des Kunden nicht erfüllt. Es ist möglich, dass das Projektteam das Budget und die Fristen eingehalten hat, der Erfolg jedoch ausgeblieben ist, weil die Geschäftsanforderungen des Kunden nicht erfüllt wurden.
• Programm-Management. Die Hauptaufgabe dieses Rollenclusters besteht darin, sicherzustellen, dass die Lösung innerhalb der Projektbeschränkungen implementiert wird. Hierzu werden der Projektzeitplan, der Arbeitsaufwand und das für das Projekt bereitgestellte Budget kontrolliert. Der jeweilige Cluster gewährleistet das rechtzeitige Erreichen der geforderten Ergebnisse und die Erfüllung der Erwartungen des Sponsors während der gesamten Projektlaufzeit.
  In Version MSF 4 wurde der Cluster „Architekturmanagement“ aus diesem Rollencluster entfernt, der die Organisation und Ausführung des High-Level-Lösungsentwurfs, die Erstellung einer funktionalen Softwarespezifikation und die Verwaltung dieser Spezifikation während des Entwicklungsprozesses sowie die Definition des Projektumfangs und der Schlüsselgeschäfte umfasst -Off-Entscheidungen.
• Entwicklung. Die Hauptaufgabe des Rollenclusters „Entwicklung“ besteht darin, die Lösung gemäß der Spezifikation zu erstellen. Bei der Umsetzung geht es darum, eine Lösung zu schaffen, die den Erwartungen des Kunden und den im Pflichtenheft formulierten Bedingungen entspricht. Außerdem folgt dieser Rollencluster strikt der entwickelten Architektur und dem Design der Lösung, die zusammen mit der funktionalen Spezifikation eine zusammenfassende Beschreibung des Endprodukts darstellen.
• Testen. Die Aufgabe dieses Rollenclusters besteht darin, die Freigabe eines Produkts erst zu genehmigen, nachdem alle Mängel identifiziert und behoben wurden. Beliebig Software enthält Mängel. Aber sie müssen alle entdeckt und behoben werden, bevor das Produkt auf den Markt kommt. Die Behebung eines Fehlers kann eine Vielzahl von Lösungen umfassen, die von der Beseitigung bis zur Dokumentation von Problemumgehungen für den Fehler reichen. Die Lieferung eines Produkts mit einem bekannten Mangel, aber mit einer Beschreibung, wie dieser behoben werden kann, ist der Lieferung eines Produkts mit einem unerkannten Mangel vorzuziehen.
• Kundenzufriedenheit (User Experience). Der Zweck dieses Rollenclusters besteht darin, die Effizienz der Produktnutzung zu verbessern.
• Release-Management. Das Ziel dieses Rollenclusters ist die reibungslose Implementierung und Wartung des Produkts. Diese Rolle dient als Verbindung zwischen dem Projektteam und den Wartungsprozessgruppen.

Das Vorhandensein der aufgeführten Rollencluster bedeutet nicht, dass das Team unbedingt aus der gleichen Anzahl an Teilnehmern bestehen muss. Ein Mitarbeiter kann durchaus mehrere Rollen vereinen, es wird jedoch nicht empfohlen, einige Rollen zu kombinieren, und einige Rollen sollten überhaupt nicht kombiniert werden. Tabelle 1 zeigt die Kompatibilitätsmatrix von Rollenclustern.

D – akzeptabel, N – inakzeptabel, N/F – nicht wünschenswert

Bei der Analyse dieser Matrix können folgende Schlussfolgerungen gezogen werden:

• Es ist nicht akzeptabel, die Rollencluster Produktmanagement und Programmmanagement zu kombinieren.
• Der Rollencluster „Entwicklung“ kann nicht mit anderen Rollenclustern kombiniert werden.
• Kombinationen anderer Cluster sind akzeptabel, Teile davon sind jedoch unerwünscht.

Beispielsweise haben Produktmanagement und Programmmanagement widersprüchliche Interessen und sollten daher nicht zusammengelegt werden. Ziel des Produktmanagements ist die Zufriedenheit des Kunden, während das Programmmanagement dafür sorgt, dass das Produkt innerhalb der vorgegebenen Zeit und des vorgegebenen Budgets fertig ist. Wenn diese Rollen kombiniert werden, besteht das Risiko, dass eine vom Kunden gewünschte Änderung entweder nicht gebührend berücksichtigt oder akzeptiert wird, ohne dass ihre Auswirkungen auf das Projekt ordnungsgemäß analysiert werden. Darstellung dieser Rollen von verschiedenen Leuten im Projektteam sorgt für einen Ausgleich zwischen zwei gegensätzlichen Standpunkten. Das Gleiche gilt für den Versuch, die Entwicklungs- und Testrollen zu kombinieren.

Somit kann ein Mindestteam, das die MSF-Methodik verwendet, aus nur drei Personen bestehen, die Rollencluster wie folgt kombinieren (Abb. 2):

• Kundenzufriedenheit, Produktmanagement, Tests.
• Programmmanagement, Release-Management.
• Entwicklung.

Beachten Sie, dass eine solche Rollenverteilung über die Matrix uneingeschränkt zulässig ist und zwei wesentliche Einschränkungen erfüllt sind: Die Entwicklerrolle ist nicht mit einer anderen Rolle kombinierbar; und es gibt keine Kombination von Rollen, die vorgegebene Interessenkonflikte aufweisen. Erwähnenswert ist auch die Empfehlung von Microsoft bezüglich der Rollenkombination: Wenn ein Projektteam aus sechs oder weniger Mitgliedern besteht, die alle Projektrollen wahrnehmen, werden die Projektmanagementaktivitäten vom Rollencluster „Programmmanagement“ durchgeführt.

Wenn es erforderlich ist, die Anzahl der Projektteilnehmer zu erhöhen (ab 10), bietet Microsoft die Aufteilung großer Teams in kleine Gruppen von Bereichen (Feature-Teams) an. Solche Gruppen arbeiten parallel, mit ständiger Synchronisierung der Arbeitsergebnisse. Dadurch erfolgt eine flexible Skalierung des Projektteammodells. Ein Beispiel für eine Skalierungsmöglichkeit ist in Abb. 3 dargestellt.

Als letzte Schlussfolgerung aus dem Artikel sagte Steve C. McConnell: „Selbst bei qualifizierten, motivierten und hart arbeitenden Menschen kann eine schlechte Teamstruktur ihre Bemühungen eher untergraben als zum Erfolg führen.“ Qualität, verminderte Arbeitsmoral, erhöhte Personalfluktuation und letztlich zum Scheitern des Projekts führen.“

Somit wird eine kompetente Organisation der Teamstruktur unter Umsetzung der Grundprinzipien der MSF-Methodik die Grundlage für den Erfolg des Projekts sein und Projektteams effektiver und erfolgreicher machen.