Lebenszyklus für Systementwicklung
Im Systemtechnik, Informationssysteme und Softwareentwicklung, das Lebenszyklus für Systementwicklung (SDLC), auch als die bezeichnet Anwendungsentwicklung Lebenszyklus, ist ein Prozess zum Planen, Erstellen, Testen und Bereitstellen eines Informationssystem.[1] Das Systementwicklungszykluskonzept gilt für eine Reihe von Hardware- und Softwarekonfigurationen, da ein System nur aus Hardware, nur Software oder einer Kombination aus beiden besteht.[2] In diesem Zyklus gibt es in der Regel sechs Stufen: Anforderungenanalyse, Design, Entwicklung und Test, Implementierung, Dokumentation und Bewertung.
Überblick
Ein Lebenszyklus zur Lebenszyklus für Systementwicklungen besteht aus einer Reihe klar definierter und unterschiedlicher Arbeitsphasen, die von Systemingenieuren und Systementwicklern verwendet werden, um zu planen, zu entwerfen, zu bauen, zu testen und zu liefern Informationssysteme. Wie alles, was auf einer Montagelinie hergestellt wird, zielt ein SDLC darauf ab, qualitativ hochwertige Systeme zu produzieren, die die Kundenerwartungen erfüllen oder übertreffen, die auf den Kundenanforderungen basieren, indem Systeme in den geplanten Zeitrahmen und Kostenschätzungen durch jede klar definierte Phase geliefert werden.[3] Computersysteme sind komplex und häufig (insbesondere mit dem jüngsten Anstieg von Serviceorientierte Architektur) Verbinden Sie mehrere herkömmliche Systeme, die möglicherweise von verschiedenen Softwareanbietern geliefert werden. Um diese Komplexität zu verwalten, wurden eine Reihe von SDLC -Modellen oder -Methoden erstellt, wie z. Wasserfall, Spiral-, Agile Software Entwicklung, Rapid-Prototyping, inkrementellund synchronisieren und stabilisieren.[4]
SDLC kann entlang eines agilen Spektrums von iterativ zu sequentiellen Methoden beschrieben werden. Agile Methoden, wie z. XP und GedrängeKonzentrieren Sie sich auf leichte Prozesse, die schnelle Änderungen (ohne unbedingt dem Muster des SDLC -Ansatzes) entlang des Entwicklungszyklus ermöglichen.[5] Iterativ Methoden wie z. Rational einheitlicher Prozess und Dynamische SystementwicklungsmethodeKonzentrieren Sie sich auf begrenzte Projektumfang und Erweiterung oder Verbesserung von Produkten durch mehrere Iterationen. Sequentielle oder Big-Design-Up-Front-Modelle (BDUF) wie Wasserfall konzentrieren sich auf die vollständige und korrekte Planung, um große Projekte und Risiken zu erfolgreichen und vorhersehbaren Ergebnissen zu steuern. Andere Modelle, wie z. anamorphe Entwicklung, neigen dazu, sich auf eine Entwicklung zu konzentrieren, die von Projektumfang und adaptiven Iterationen der Merkmalsentwicklung geleitet wird.
Im Projektmanagement Ein Projekt kann beide mit a definiert werden Projektlebenszyklus (PLC) und ein SDLC, bei dem leicht unterschiedliche Aktivitäten auftreten. Laut Taylor (2004) "umfasst der Projektlebenszyklus alle Aktivitäten der Projekt, während sich der Lebenszyklus der Systementwicklung auf die Realisierung des Produkts konzentriert Bedarf".[6]
Das SDLC ist keine Methodik an sich, sondern eine Beschreibung der Phasen im Lebenszyklus einer Softwareanwendung. In einem breiten Sinne sind diese Phasen: Untersuchung, Analyse, Design, Erstellung, Test, Implementierung sowie Wartung und Unterstützung. Alle Softwareentwicklungsmethoden folgen den SDLC -Phasen, aber die Methode, die zu tun ist, variiert stark zwischen den Methoden. Im Scrum -Framework,[7] Zum Beispiel könnte man sagen, dass eine einzelne Benutzergeschichte in einem einzelnen zweiwöchigen Sprint durch alle Phasen des SDLC geht. Vergleichen Sie dies der Wasserfallmethode als ein weiteres Beispiel, bei dem jede Geschäftsanforderung (aufgezeichnet in der Analysephase des SDLC in einem Dokument, das als Geschäftsanforderungen Spezifikation bezeichnet wird) in Feature/Functional -Beschreibungen übersetzt (in der Entwurfsphase in einem Dokument namens genannt Die funktionale Spezifikation), die dann alle in einem GO als Sammlung von Lösungsmerkmalen in der Regel über einen Zeitraum von drei bis neun Monaten oder mehr integriert sind. Diese Methoden sind unterschiedliche Ansätze, aber beide enthalten die SDLC Version der Softwareanwendung.
Geschichte und Details
Das Produktlebensdauer beschreibt den Prozess zum Aufbau von Informationssystemen sehr bewusst, strukturiert und methodisch und wiederholt jede Phase des Produktlebens. Der Lebenszyklus für Systementwicklungslebenszyklus laut Elliott & Strachan & Radford (2004) wurde in den 1960er Jahren entstand Geschäftssysteme in einem Zeitalter großer Maßstab Geschäftskonglomerate. Aktivitäten für Informationssysteme drehten sich um schwer Datenverarbeitung und Zahlenverarbeitung Routinen ".[8]
Mehrere Systementwicklungsrahmen basieren teilweise auf SDLC, wie die Strukturierte Systemanalyse- und Entwurfsmethode (SSADM) für die britische Regierung produziert Handel des Regierungsverwalters in den 1980er Jahren. Seit laut Elliott (2004) "wurden die traditionellen Lebenszyklusansätze für die Systementwicklung zunehmend durch alternative Ansätze und Rahmenbedingungen ersetzt, die versuchten, einige der inhärenten Mängel des traditionellen SDLC zu überwinden".[8]
Phasen
Der Lebenszyklus -Rahmen für Systementwicklungen bietet eine Folge von Aktivitäten für Systemdesigner und Entwickler. Es besteht aus einer Reihe von Schritten oder Phasen, in denen jede Phase des SDLC die Ergebnisse der vorherigen verwendet.[9][10]
Die SDLC hält an wichtigen Phasen, die für Entwickler unerlässlich sind - zum Beispiel als Planung, Analyse, Entwurf, und Implementierung- und werden im Abschnitt unten erklärt. Dies beinhaltet die Bewertung des aktuell verwendeten Systems, Informationen zum Sammeln von Informationen, Machbarkeitsstudien und Anfragen der Genehmigung. Es wurde eine Reihe von SDLC -Modellen erstellt, darunter Wasserfall, Brunnen, Spirale, Build und Fix, schnelles Prototyping, inkrementell, synchronisiert und stabilisiert.[11][12] Das älteste von ihnen und das bekannteste ist das Wasserfall-Modell, Eine Abfolge von Stufen, in denen die Ausgabe jeder Stufe zum Eingang für die nächste wird.[10] Diese Phasen können auf unterschiedliche Weise charakterisiert und aufgeteilt werden, einschließlich Folgendes:[9][10][13][14]
- Voruntersuchung: Beginnen Sie mit einer vorläufigen Analyse, schlagen Sie alternative Lösungen vor, beschreiben Sie Kosten und Vorteile und geben Sie einen vorläufigen Plan mit Empfehlungen ein.
- Führen Sie die vorläufige Analyse durch: Entdecken Sie die Ziele der Organisation sowie die Art und den Umfang des untersuchten Problems. Auch wenn sich ein Problem nur auf ein kleines Segment der Organisation selbst bezieht, finden Sie heraus, was die Ziele der Organisation selbst sind. Dann sehen Sie, wie das Problem zu ihnen passt.
- Alternative Lösungen vorschlagen: Nach dem Graben in die Ziele und spezifischen Probleme der Organisation wurden möglicherweise mehrere Lösungen entdeckt. Allerdings können jedoch auch alternative Vorschläge aus der Befragung von Mitarbeitern, Kunden, Lieferanten und/oder Beratern zurückzuführen sein. Einblicke können auch durch die Erforschung der Untersuchung, was Wettbewerber tun, gewonnen werden.
- Kostenvorteilanalyse: Analysieren und beschreiben Sie die Kosten und Vorteile der Umsetzung der vorgeschlagenen Änderungen. Letztendlich wird die ultimative Entscheidung darüber, ob das System so verlassen wird, es zu verbessern, ein neues System zu verbessern oder ein neues System zu entwickeln, von diesem und dem Rest der vorläufigen Analysedaten geleitet wird.
- Systemanalyse, Anforderungen Definition: Definieren Sie die Projektziele in definierten Funktionen und Operationen der beabsichtigten Anwendung. Dies beinhaltet den Prozess des Sammelns und Interpretierens von Fakten, Diagnose von Problemen und der Empfehlung von Verbesserungen des Systems. Die Projektziele werden durch die Analyse des Endbenutzerinformationsbedarfs und der Entfernung von Inkonsistenzen und Unvollständigkeit dieser Anforderungen weiter unterstützt.
- Eine Reihe von Schritten, gefolgt vom Entwickler, umfasst:[15]
- Sammlung von Fakten: Erhalten Sie Endbenutzeranforderungen durch Dokumentation, Kundeninterviews, Beobachtung und Fragebögen.
- Prüfung des vorhandenen Systems: Identifizieren Sie Vor- und Nachteile des aktuellen Systems an Ort und Stelle, um die Profis voranzutreiben und die Nachteile im neuen System zu vermeiden.
- Analyse des vorgeschlagenen Systems: Finden Sie Lösungen für die in Schritt zwei beschriebenen Mängel und bereiten Sie die Spezifikationen mit bestimmten Benutzernvorschlägen vor.
- Systemdesign: In diesem Schritt werden die gewünschten Funktionen und Vorgänge ausführlich beschrieben, einschließlich Bildschirmlayouts. Geschäftsregeln, Prozessdiagramme, Pseudocodeund andere Dokumentation.
- Entwicklung: Der wahre Code ist hier geschrieben.
- Integration und Test: Alle Module werden in eine spezielle Testumgebung zusammengefasst und dann auf Fehler, Fehler und Interoperabilität überprüft.
- Akzeptanz, Installation, Bereitstellung: Dies ist die endgültige Phase der ersten Entwicklung, in der die Software in Produktion gesteckt wird und tatsächliche Geschäfte betreibt.
- Wartung: Während der Wartungsphase des SDLC wird das System bewertet/bewertet, um sicherzustellen, dass es nicht veraltet ist. Hier werden auch Änderungen an der ersten Software vorgenommen.
- Auswertung: Einige Unternehmen betrachten dies nicht als offizielle Phase des SDLC, während andere es als Erweiterung der Wartungsphase betrachten und in einigen Kreisen als Überprüfung nach der Implementierung bezeichnet werden können. Hier wird das System sowie der gesamte Prozess bewertet. Einige der Fragen, die beantwortet werden müssen, umfassen, wenn das neu implementierte System die anfänglichen Geschäftsanforderungen und -ziele erfüllt, wenn das System zuverlässig und fehlertolerant ist und ob es gemäß den genehmigten funktionalen Anforderungen funktioniert. Zusätzlich zur Bewertung der freigegebenen Software ist es wichtig, die Wirksamkeit des Entwicklungsprozesses zu bewerten. Wenn es Aspekte des gesamten Prozesses (oder bestimmten Phasen) gibt, mit denen das Management nicht zufrieden ist, ist dies die Zeit, um sich zu verbessern.
- Verfügung: In dieser Phase werden Pläne entwickelt, um die Verwendung von Systeminformationen, Hardware und Software abzubrechen und den Übergang zu einem neuen System zu machen. Der Zweck hier ist es, Informationen, Hardware und Software, die ersetzt wird, so ersetzt, die Möglichkeiten einer nicht autorisierten Offenlegung sensibler Daten zu verhindern, zu archivieren, zu verwerfen oder zu zerstören. Die Entsorgungsaktivitäten gewährleisten eine ordnungsgemäße Migration in ein neues System. Ein besonderer Schwerpunkt liegt auf der ordnungsgemäßen Erhaltung und Archivierung von Daten, die vom vorherigen System verarbeitet wurden. All dies sollte gemäß den Sicherheitsanforderungen der Organisation erfolgen.[16]
Im folgenden Diagramm sind diese Phasen des Lebenszyklus der Systementwicklung in zehn Schritten aufgeteilt, von Definition bis zur Erstellung und Modifikation von IT -Arbeitsprodukten:
Nicht jedes Projekt erfordert, dass die Phasen nacheinander ausgeführt werden. Die Phasen sind jedoch voneinander abhängig. Abhängig von der Größe und Komplexität des Projekts können Phasen kombiniert oder überlappen.[9]
Systemuntersuchung
Zunächst wird der IT -Systemvorschlag untersucht. Berücksichtigen Sie während dieses Schritts alle aktuellen Prioritäten, die betroffen wären und wie sie behandelt werden sollten. Bevor eine Systemplanung abgeschlossen ist, a Machbarkeitsstudie sollte durchgeführt werden, um festzustellen, ob das Erstellen eines neuen oder verbesserten Systems eine praktikable Lösung ist. Dies wird dazu beitragen, die Kosten, Leistungen, Ressourcenanforderungen und spezifische Benutzeranforderungen für den Fertigstellung zu bestimmen. Der Entwicklungsprozess kann erst nach dem Management fortgesetzt werden, wenn die Empfehlungen aus der Machbarkeitsstudie genehmigt werden.
Die folgenden stellen verschiedene Komponenten der Machbarkeitsstudie dar:
- Operative Machbarkeit
- Finanzielle Machbarkeit
- Technische Machbarkeit
- Machbarkeit des menschlichen Faktoren
- Rechtliche/politische Machbarkeit
Analyse
Das Ziel von Analyse soll feststellen, wo sich das Problem befindet, um das System zu beheben. Dieser Schritt beinhaltet zusammenbrechen Das System in verschiedenen Teilen zur Analyse der Situation, der Analyse von Projektzielen, dem Aufschlachen, was geschaffen werden muss, und versuchen, Benutzer zu engagieren, damit eindeutige Anforderungen definiert werden können.
Entwurf
Im SystemdesignDie Entwurfsfunktionen und -Operationen werden ausführlich beschrieben, einschließlich Bildschirmlayouts, Geschäftsregeln, Prozessdiagramme und anderer Dokumentation. Die Ausgabe dieser Phase beschreibt das neue System als Sammlung von Modulen oder Subsystemen.
Die Entwurfsphase nimmt als anfängliche Eingabe die im genehmigten Anforderungsdokument identifizierten Anforderungen an. Für jede Anforderung wird eine Reihe eines oder mehrerer Entwurfselemente aufgrund von Interviews, Workshops und/oder Prototypanstrengungen erstellt.
Designelemente beschreiben die gewünschten Systemmerkmale im Detail und umfassen im Allgemeinen funktionale Hierarchiediagramme, Bildschirmlayoutdiagramme, Tabellen der Geschäftsregeln, Geschäftsprozessdiagramme, Pseudo-Code und ein vollständiges Entitätsbeziehungsdiagramm mit einem vollständigen Datenwörterbuch. Diese Designelemente sollen das System ausreichend beschreiben, sodass qualifizierte Entwickler und Ingenieure das System mit minimalem zusätzlichen Eingangsdesign entwickeln und liefern können.
Umgebungen
Umgebungen sind kontrollierte Bereiche, in denen Systemeentwickler Systeme erstellen, verteilen, installieren, konfigurieren, testen und ausführen können, die sich durch die SDLC bewegen. Jede Umgebung ist mit verschiedenen Bereichen des SDLC ausgerichtet und soll spezifische Zwecke haben. Beispiele für solche Umgebungen umfassen:
- Entwicklungsumgebung, wo Entwickler unabhängig voneinander arbeiten können, bevor sie versuchen, ihre Arbeit mit der Arbeit anderer zu verschmelzen;
- Gemeinsame Bauumgebung, wo zusammengeführte Arbeiten zusammen als kombiniertes System gebaut werden können;
- Systemintegrationstestumgebung, wenn grundlegende Tests der Integration eines Systems auf andere stromaufwärts gelegene oder nachgeschaltete Systeme getestet werden können;
- Umgebung für Benutzerakzeptanztests, wo Geschäftstakeholder gegen ihre ursprünglichen Geschäftsanforderungen testen können; und
- Produktionsumfeld, wo Systeme endlich von ihren beabsichtigten Endbenutzern zur endgültigen Verwendung eingesetzt werden.
Testen
Der Code wird auf verschiedenen Ebenen in getestet Softwaretest. Einheit, System- und Benutzerakzeptanzverkostungen werden häufig durchgeführt. Dies ist eine Grauzone, da viele verschiedene Meinungen darüber bestehen, was die Teststadien sind und wie viel, wenn eine Iteration stattfindet. Die Iteration ist im Allgemeinen nicht Teil des Wasserfallmodells, aber die Mittel zur Behebung von Mängel und die Validierung von Fixes vor dem Einsatz sind in diese Phase aufgenommen.
Die folgenden Testtypen sind je nach Entwicklungstyp relevant:
- Defekttests die fehlgeschlagenen Szenarien, einschließlich
- Pfadtests
- Datensatzstests
- Unit -Tests
- Systemtests
- Integrationstests
- Black-Box-Tests
- White-Box-Test
- Regressionstests
- Automatisierungstests
- User Acceptance Testing
- Software -Leistungstests
Training und Übergang
Sobald ein System durch angemessene Tests stabilisiert wurde, stellt die SDLC sicher, dass eine ordnungsgemäße Schulung des Systems durchgeführt oder dokumentiert wird, bevor das System zu seinen Support -Mitarbeitern und Endbenutzern übergeht. Das Training deckt in der Regel eine operative Schulung für diejenigen Personen ab, die für die Unterstützung des Systems verantwortlich sind, sowie für die Schulung für diejenigen Endbenutzer, die das System nach seiner Bereitstellung in eine Produktionsbetriebsumgebung verwenden.
Nach erfolgreichem Training wechseln Systemingenieure und Entwickler das System in seine endgültige Produktionsumgebung, in der es von seinen Endbenutzern verwendet und von seinen Support- und Betriebspersonal unterstützt werden soll.
Betrieb und Wartung
Das Einsatz des Systems umfasst verschiedene Änderungen und Verbesserungen vor der Stilllegung oder Sonnenuntergang des Systems. Aufrechterhaltung Das System ist ein sehr wichtiger Aspekt von SDLC. Wenn Schlüsselpersonal Positionen in der Organisation ändern, werden neue Änderungen umgesetzt. Es gibt zwei Ansätze zur Systementwicklung: den traditionellen Ansatz (strukturiert) und objektorientierter. Informationstechnik umfasst den traditionellen Systemansatz, der auch als strukturierte Analyse- und Designtechnik bezeichnet wird. Der objektorientierte Ansatz betrachtet ein Informationssystem als Sammlung von Objekten, die ineinander integriert sind, um ein vollständiges und vollständiges Informationssystem zu erstellen.
Auswertung
Die letzte Phase des SDLC besteht darin, die Wirksamkeit des Systems zu messen und potenzielle Verbesserungen zu bewerten.
Systemanalyse und Design
Das Systemanalyse und Design (SAD) Ist der Prozess der Entwicklung von Informationstechnologiesystemen (ITS), die Hardware, Software, Daten, Prozesse und Personen effektiv verwenden, um die Unternehmensziele des Unternehmens zu unterstützen. Es ist ein Prozess der Planung eines neuen Geschäftssystems oder des Ersetzens eines vorhandenen Systems, indem es seine Komponenten oder Module definiert, um bestimmte Anforderungen zu erfüllen. Die Systemanalyse und das Design können als Metaentwicklungsaktivität angesehen werden, die dazu dient, die Bühne zu setzen und das Problem zu begrenzen. SAD kann genutzt werden, um das richtige Gleichgewicht zwischen konkurrierenden hochrangigen Anforderungen in den funktionellen und nicht funktionalen Analysedomänen festzulegen. Systemanalyse und -design interagieren stark mit verteilter Enterprise -Architektur, Enterprise I.T. Architektur und Geschäftsarchitektur und stützt sich stark auf Konzepte wie Partitionierung, Schnittstellen, Persona und Rollen sowie Bereitstellungs-/Betriebsmodellierung, um zu einer Systembeschreibung auf hoher Ebene zu gelangen. Diese Beschreibung auf hoher Ebene wird dann weiter in die Komponenten und Module unterteilt, die separat analysiert, entworfen und konstruiert und integriert werden können, um das Geschäftsziel zu erreichen. SDLC und SAD sind Eckpfeiler der Produkt- und Systemplanung des Lebenszyklus.
Objektorientierte Analyse
Die objektorientierte Analyse (OOA) ist der Prozess der Analyse einer Aufgabe (auch als Problemdomäne bezeichnet) ein konzeptionelles Modell, mit dem dann die Aufgabe erledigt werden kann. Ein typisches OOA-Modell würde Computersoftware beschreiben, die verwendet werden könnte, um eine Reihe von kundendefinierten Anforderungen zu erfüllen. Während der Analysephase der Problemlösung kann ein Programmierer eine schriftliche Anforderungen, ein formelles Visionsdokument oder Interviews mit Stakeholdern oder anderen interessierten Parteien in Betracht ziehen. Die zu behandelnde Aufgabe kann in mehrere Unteraufgaben (oder Bereiche) unterteilt werden, die jeweils ein anderes Geschäft, technologische oder andere Interessenbereiche darstellen. Jede Subtask würde separat analysiert. Implementierungsbeschränkungen (z. B.,, Parallelität, Verteilung, Beharrlichkeit, oder wie das System aufgebaut werden soll) werden während der Analysephase nicht berücksichtigt; Sie werden vielmehr während des objektorientierten Designs (OOD) angesprochen.
Das konzeptionelle Modell, das von OOA resultiert Anwendungsfälle, ein oder mehr Uml Klassendiagrammeund eine Reihe von Interaktionsdiagramme. Es kann auch eine Art von einer Art beinhalten Benutzeroberfläche Attrappe, Lehrmodell, Simulation.
Die Eingabe für objektorientiertes Design erfolgt durch die Ausgabe von Objektorientierte Analyse. Erkennen Sie, dass ein Ausgangsartefakt nicht vollständig entwickelt werden muss, um als Eingabe eines objektorientierten Designs zu dienen. Analyse und Design können parallel auftreten, und in der Praxis können die Ergebnisse einer Aktivität den anderen in einem kurzen Rückkopplungszyklus durch einen iterativen Prozess ernähren. Sowohl die Analyse als auch das Design können schrittweise durchgeführt werden, und die Artefakte können kontinuierlich angebaut werden, anstatt vollständig in einer Aufnahme zu entwickeln.
Einige typische (aber für alle Arten von Designanalyse) in Eingabeartefakte für objektorientiertes Eingangsartefakte:
- Konzeptmodell: Konzeptionelles Modell ist das Ergebnis einer objektorientierten Analyse. Es erfasst Konzepte im Problembereich. Das konzeptionelle Modell wird explizit als unabhängig von Implementierungsdetails wie Parallelität oder Datenspeicherung ausgewählt.
- Anwendungsfall: Anwendungsfall ist eine Beschreibung von Ereignissequenzen, die zusammen dazu führen, dass ein System etwas Nützliches tut. Jeder Anwendungsfall bietet einen oder mehrere Szenarien Dies vermittelt, wie das System mit den Benutzern interagieren sollte, die als Akteure berufen werden, um ein bestimmtes Geschäftsziel oder eine bestimmte Funktion zu erreichen. Anwendungsfallakteure können Endbenutzer oder andere Systeme sein. In vielen Umständen werden Anwendungsfälle weiter in Anwendungsfalldiagramme ausgearbeitet. Anwendungsfalldiagramme werden verwendet, um den Akteur (Benutzer oder andere Systeme) und die von ihnen durchgeführten Prozesse zu identifizieren.
- Systemsequenzdiagramm: Systemsequenzdiagramm (SSD) ist ein Bild, das für ein bestimmtes Szenario eines Anwendungsfalls die Ereignisse, die externe Akteure erzeugen, ihre Ordnung und mögliche Inter-System-Ereignisse zeigen.
- Dokumentationen der Benutzeroberfläche (falls zutreffend): Dokument, das die zeigt und beschreibt schauen und fühlen der Benutzeroberfläche des Endprodukts. Es ist nicht obligatorisch, dies zu haben, aber es hilft, das Endprodukt zu visualisieren, und hilft daher dem Designer.
- Relationales Datenmodell (falls zutreffend): Ein Datenmodell ist ein abstraktes Modell, das beschreibt, wie Daten dargestellt und verwendet werden. Wenn ein Objektdatenbank wird nicht verwendet, das relationale Datenmodell sollte normalerweise vor dem Entwurf erstellt werden, da die Strategie für die ausgewählte Strategie Objektrelationskartierung ist eine Ausgabe des OO -Designprozesses. Es ist jedoch möglich, das relationale Datenmodell und die objektorientierten Designartefakte parallel zu entwickeln, und das Wachstum eines Artefakts kann die Verfeinerung anderer Artefakte stimulieren.
Lebenszyklus
Management und Kontrolle
Die SDLC -Phasen dienen als programmatische Leitfaden für Projektaktivitäten und bieten eine flexible, aber konsistente Möglichkeit, Projekte in einer Tiefe durchzuführen, die dem Projektumfang entspricht. Jedes der SDLC -Phasenziele wird in diesem Abschnitt mit wichtigen Ergebnissen, einer Beschreibung der empfohlenen Aufgaben und einer Zusammenfassung der zugehörigen Kontrollziele für das effektive Management beschrieben. Für den Projektmanager ist es entscheidend, während jeder SDLC -Phase Kontrollziele festzulegen und zu überwachen, während sie Projekte ausführen. Kontrollziele helfen dabei, eine klare Aussage über das gewünschte Ergebnis oder Zweck zu ermitteln, und sollte während des gesamten SDLC -Prozesss verwendet werden. Kontrollziele können in Hauptkategorien (Domänen) eingeteilt werden und beziehen sich auf die SDLC -Phasen, wie in der Abbildung gezeigt.[17]
Um eine SDLC -Initiative zu verwalten und zu kontrollieren, muss jedes Projekt einen gewissen Grad von a festlegen Arbeitsumbruchstruktur (WBS) Erfassen und Planen der für die Abschluss des Projekts erforderlichen Arbeiten. Das WBS und das gesamte programmatische Material sollten im Abschnitt "Projektbeschreibung" des Projektnotels aufbewahrt werden. Das WBS -Format bleibt dem Projektmanager hauptsächlich überlassen, sich auf eine Weise zu etablieren, die die Projektarbeit am besten beschreibt.
Es gibt einige Schlüsselbereiche, die im WBS als Teil der SDLC -Richtlinie definiert werden müssen. Das folgende Diagramm beschreibt drei Schlüsselbereiche, die in der WBS auf eine vom Projektmanager festgelegte Weise behandelt werden.[17] Das Diagramm zeigt, dass die Abdeckung zahlreiche Phasen des SDLC umfasst, aber die zugehörige MCD hat eine Untergruppe von primären Zuordnungen zu den SDLC -Phasen. Beispielsweise wird Analyse und Design in erster Linie im Rahmen des Erwerbs- und Implementierungsbereichs und des Systemaufbaus durchgeführt und der Prototyp wird hauptsächlich als Teil der Lieferung und Unterstützung durchgeführt.
Strukturierte Organisation für Arbeitsaufschlüsse
Der obere Abschnitt der Arbeitsaufschlüsselungsstruktur (WBS) sollte die Hauptphasen und Meilensteine des Projekts zusammenfassend identifizieren. Darüber hinaus sollte der obere Abschnitt einen Überblick über den vollständigen Umfang und die Zeitleiste des Projekts bieten und Teil der ersten Projektbeschreibungsprodukte sein, die zur Projektgenehmigung führen. Der mittlere Abschnitt des WBS basiert auf den sieben Systementwicklungszyklus -Phasen als Leitfaden für die Entwicklung der WBS -Aufgaben. Die WBS -Elemente sollten aus Meilensteinen und "Aufgaben" im Gegensatz zu "Aktivitäten" bestehen und eine endgültige Periode haben (normalerweise zwei Wochen oder mehr). Jede Aufgabe muss eine messbare Ausgabe haben (E.X. Dokument, Entscheidung oder Analyse). Eine WBS -Aufgabe kann auf eine oder mehrere Aktivitäten (z. B. Software -Engineering, Systemtechnik) beruhen und eine enge Koordination mit anderen Aufgaben erfordern, die entweder intern oder extern zum Projekt sind. Jeder Teil des Projekts, der Unterstützung von Auftragnehmern benötigt, sollte a haben Lastenheft (Sow) geschrieben, um die entsprechenden Aufgaben aus den SDLC -Phasen einzubeziehen. Die Entwicklung einer Sau erfolgt nicht während einer bestimmten Phase von SDLC, sondern wird entwickelt, um die Arbeiten aus dem SDLC -Prozess einzubeziehen, das von externen Ressourcen wie Auftragnehmern durchgeführt werden kann.[17]
Grundlinien
Baselines sind ein wichtiger Bestandteil des Lebenszyklus für Systementwicklungszyklus. Diese Baselines werden nach vier der fünf Phasen des SDLC festgelegt und sind für die iterative Natur des Modells von entscheidender Bedeutung.[18] Jede Grundlinie wird als Meilenstein im SDLC angesehen.
- Funktionelle Grundlinie: Nach der konzeptionellen Designphase festgelegt.
- Zugewiesene Basislinie: Nach der vorläufigen Entwurfsphase eingerichtet.
- Produktbasis: Nach der Detaildesign- und Entwicklungsphase eingerichtet.
- Aktualisierte Produktbasis: Nach der Produktionsstättesphase eingerichtet.
Komplementäre Methoden
Komplementär Softwareentwicklungsmethoden Der Lebenszyklus für Systemeentwicklungszyklus sind:
- Software -Prototyping
- Gemeinsame Anwendungsentwicklung (JAD)
- Schnelle Anwendungsentwicklung (Rad)
- Extremes Programmieren (Xp);
- Open-Source-Entwicklung
- Endbenutzerentwicklung
- Objekt orientierte Programmierung
SDLC | Rad | Open Source | Objekte | Jad | Prototyp entwickeln | Endbenutzer | |
---|---|---|---|---|---|---|---|
Kontrolle | Formell | Mis | Schwach | Standards | Gemeinsam | Benutzer | Benutzer |
Zeitfenster | Lang | Kurz | Mittel | Irgendein | Mittel | Kurz | Kurz – |
Benutzer | Viele | Wenig | Wenig | Variiert | Wenig | Ein oder zwei | Einer |
MIS -Mitarbeiter | Viele | Wenig | Hunderte | Teilt | Wenig | Ein oder zwei | Keiner |
Transaktion/DSS | Transaktion | Beide | Beide | Beide | DSS | DSS | DSS |
Schnittstelle | Minimal | Minimal | Schwach | Fenster | Zentral | Zentral | Zentral |
Dokumentation und Schulung | Vital | Begrenzt | Intern | In Objekten | Begrenzt | Schwach | Keiner |
Integrität und Sicherheit | Vital | Vital | Unbekannt | In Objekten | Begrenzt | Schwach | Schwach |
Wiederverwendbarkeit | Begrenzt | Etwas | Vielleicht | Vital | Begrenzt | Schwach | Keiner |
Stärken und Schwächen
Nur wenige Menschen in der modernen Computerwelt würden ein strenges Wasserfallmodell für ihr SDLC verwenden, da viele moderne Methoden dieses Denken abgelöst haben. Einige werden argumentieren, dass die SDLC nicht mehr für Modelle wie Agile Computing gilt, sondern in Technologiekreisen immer noch ein Begriff ist. Die SDLC -Praxis hat Vorteile in traditionellen Modellen der Systementwicklung, die sich mehr für eine strukturierte Umgebung eignen. Die Nachteile bei der Verwendung der SDLC-Methodik besteht darin, wenn die iterative Entwicklung oder (d. H. Webentwicklung oder E-Commerce) erforderlich ist, wenn die Stakeholder die sozidische Software regelmäßig überprüfen müssen.
Ein Vergleich der Stärken und Schwächen von SDLC:
Stärken | Schwächen |
---|---|
Kontrolle | Erhöhte Entwicklungszeit |
Große Projekte überwachen | Erhöhte Entwicklungskosten |
Detaillierte Schritte | Systeme müssen vorne definiert werden |
Bewerten Sie Kosten und Fertigstellungziele | Steifigkeit |
Dokumentation | Schwer zu schätzen Kosten, Projektüberschreitungen |
Gut definierte Benutzereingabe | Benutzereingabe ist manchmal begrenzt |
Leichte Wartung | Kleine Parallelität |
Entwicklungs- und Designstandards | Die Automatisierung von Dokumentation und Standards ist begrenzt |
Toleriert Veränderungen im MIS des Personals | Toleriert keine Änderungen der Anforderungen |
Projekte, die früh in der Folge von geringer oder garem Wert konserviert sind |
Eine Alternative zum SDLC ist eine schnelle Anwendungsentwicklung, die Prototyping, gemeinsame Anwendungsentwicklung und Implementierung von Fallwerkzeugen kombiniert. Die Vorteile von RAD sind Geschwindigkeit, reduzierte Entwicklungskosten und aktive Benutzerbeteiligung am Entwicklungsprozess.
Systemlebenszyklus
Der Systemlebenszyklus in Systemtechnik ist eine Ansicht eines Systems oder eines vorgeschlagenen Systems, das alle Phasen seiner Existenz so behandelt, dass Systemkonzeption, Design und Entwicklung, Produktion und/oder Konstruktion, Verteilung, Betrieb, Wartung und Unterstützung, Ruhestand, Ausstieg und Entsorgung gehören.[20]
Konzeptionelles Design
Das konzeptionelles Design Stadium ist die Stufe, in der ein identifizierter Bedarf untersucht wird, die Anforderungen an potenzielle Lösungen definiert werden, potenzielle Lösungen bewertet und eine Systemspezifikation entwickelt werden. Die Systemspezifikation stellt die technischen Anforderungen dar, die allgemeine Leitlinien für das Systemdesign bieten. Da dieses Dokument die gesamte zukünftige Entwicklung bestimmt, kann die Bühne erst abgeschlossen werden, bis ein konzeptionelles Konzept ist Designprüfung hat festgestellt, dass die Systemspezifikation den motivierenden Bedarf ordnungsgemäß erfüllt.
Zu den wichtigsten Schritten in der konzeptionellen Designphase gehören:
- Benötigen Identifikation
- Machbarkeitsanalyse
- Analyse der Systemanforderungen
- System Spezifikation
- Konzeptioneller Design Review
Vorläufiger Systemdesign
In dieser Phase des Systemlebenszyklus werden Subsysteme, die die gewünschten Systemfunktionen ausführen, in Übereinstimmung mit der Systemspezifikation entworfen und angegeben. Schnittstellen zwischen Subsystemen sind definiert sowie allgemeine Test- und Bewertungsanforderungen.[21] Zum Abschluss dieser Phase wird eine Entwicklungsspezifikation erstellt, die ausreicht, um ein detailliertes Design und die Entwicklung durchzuführen.
Zu den wichtigsten Schritten in der vorläufigen Designphase gehören:
- Funktionsanalyse
- Anforderungen Allokation
- Detaillierte Kompromisse
- Synthese von Systemoptionen
- Vorläufiger Konstruktion von technischen Modellen
- Entwicklungsspezifikation
- Vorläufige Designbewertung
Als Systemanalyst der Viti Bank wurden Sie beispielsweise beauftragt, das aktuelle Informationssystem zu untersuchen. Die Viti Bank ist eine schnell wachsende Bank in Fidschi. Kunden in abgelegenen ländlichen Gebieten finden Schwierigkeiten, auf die Bankdienste zuzugreifen. Es dauert Tage oder sogar Wochen, um zu einem Ort zu reisen, um auf die Bankdienste zuzugreifen. Mit der Vision, die Bedürfnisse der Kunden zu erfüllen, hat die Bank Ihre Dienste gebeten, das aktuelle System zu prüfen und Lösungen oder Empfehlungen zu ermitteln, wie das aktuelle System bereitgestellt werden kann, um seine Anforderungen zu erfüllen.
Detail Design und Entwicklung
Diese Phase umfasst die Entwicklung detaillierter Entwürfe, die die ersten Designarbeiten in eine abgeschlossene Form von Spezifikationen einbringen. Diese Arbeit umfasst die Spezifikation von Schnittstellen zwischen dem System und seiner beabsichtigten Umgebung und eine umfassende Bewertung der Systeme der Systeme logistisch, Wartung und Support. Das Detaildesign und die Detailentwicklung sind für die Herstellung der Produkt-, Prozess- und Materialspezifikationen verantwortlich und können zu erheblichen Änderungen der Entwicklungsspezifikation führen.
Zu den wichtigsten Schritten in der Detail -Design- und Entwicklungsphase gehören:
- Detailliertes Design
- Detaillierte Synthese
- Entwicklung von Engineering- und Prototypmodellen
- Überarbeitung der Entwicklungsspezifikation
- Produkt-, Prozess- und Materialspezifikation
- Kritische Entwurfsprüfung
Produktion und Konstruktion
Während der Produktion und/oder der Bauphase wird das Produkt gemäß den im Produkt-, Prozess- und Materialspezifikationen angegebenen Anforderungen erstellt oder zusammengestellt und in der operativen Zielumgebung eingesetzt und getestet. Systembewertungen werden durchgeführt, um Mängel zu korrigieren und das System zur weiteren Verbesserung anzupassen.
Zu den wichtigsten Schritten innerhalb der Produktkonstruktion gehören:
- Produktion und/oder Konstruktion von Systemkomponenten
- Akzeptanzprüfung
- Systemverteilung und Betrieb
- Betriebstests und Bewertung
- Systembewertung
Nutzung und Unterstützung
Sobald das System vollständig eingesetzt wird, wird das System für seine beabsichtigte operative Rolle verwendet und in seiner operativen Umgebung aufrechterhalten.
Zu den wichtigsten Schritten in der Nutzungs- und Unterstützungsstufe gehören:
- Systembetrieb in der Benutzerumgebung
- Änderungsmanagement
- Systemänderungen zur Verbesserung
- Systembewertung
Ausstieg und Entsorgung
Wirksamkeit und Effizienz des Systems müssen kontinuierlich bewertet werden, um festzustellen, wann das Produkt seinen maximalen effektiven Lebenszyklus erfüllt hat.[22] Zu den Überlegungen gehören: Fortsetzung des existierenden Bedarfs, Übereinstimmung zwischen Betriebsanforderungen und Systemleistung, Durchführbarkeit des Systems aus dem System und der Wartung und Verfügbarkeit alternativer Systeme.
Siehe auch
Verweise
- ^ Auswählen eines Entwicklungsansatzes. Abgerufen am 17. Juli 2014.
- ^ Parag C. Pendharkara; James A. Rodgerb; Girish H. Subramanian (November 2008). "Eine empirische Studie der Cobb -Douglas -Produktionsfunktionseigenschaften der Softwareentwicklung". Informations- und Softwaretechnologie. 50 (12): 1181–1188. doi:10.1016/j.infsof.2007.10.019.
- ^ "Systementwicklungslebenszyklus von". Ordner. Abgerufen 2013-06-14.
- ^ "Software Development Life Cycle (SDLC)".
- ^ "SDLC -Übersicht: Modelle & Methoden". Abgerufen 2021-12-12.
- ^ Taylor, James (2004). Verwaltung von Informationstechnologieprojekten. p. 39.
- ^ "Was ist Scrum?". 24. Dezember 2019.
- ^ a b Geoffrey Elliott & Josh Strachan (2004) Globale Geschäftsinformationstechnologie. S.87.
- ^ a b c d US -Justizministerium (2003). Informationsressourcenmanagement Kapitel 1 Einleitung.
- ^ a b c Everatt, G.D.; McLeod, R JR (2007). "Kapitel 2: Der Lebenszyklus der Softwareentwicklung". Softwaretests: Testen des gesamten Lebenszyklus für Softwareentwicklungszyklus. John Wiley & Sons. S. 29–58. ISBN 9780470146347.
- ^ Unelkar, B. (2016). Die Kunst der agilen Praxis: Ein zusammengesetzter Ansatz für Projekte und Organisationen. CRC Press. S. 56–59. ISBN 9781439851197.
- ^ Land, S.K.; Smith, D.B.; Walz, J.W. (2012). Praktische Unterstützung für Lean Six Sigma -Software -Prozessdefinition: Verwenden von IEEE Software Engineering Standards. John Wiley & Sons. S. 341–3. ISBN 9780470289952.
- ^ Kay, Russell (14. Mai 2002). "QuickStudy: Systementwicklungslebenszyklus". Computerwelt.
- ^ Taylor, G.D. (2008). Einführung in das Logistik -Engineering. CRC Press. S. 12.6–12.18. ISBN 9781420088571.
- ^ "Kapitel 5". Steuerung und Prüfung der Informationssysteme. Institut für Wirtschaftsprüfer in Indien. August 2013. p. 5.28.
- ^ Radack, S. (n.d.). "Der Systementwicklungslebenszyklus (SDLC)" (PDF). Nationales Institut für Standards und Technologie.
- ^ a b c d e US -Repräsentantenhaus (1999). Systementwicklung Lebenszyklusrichtlinie. S.13. Archiviert 2013-10-19 bei der Wayback -Maschine
- ^ Blanchard, B. S., & Fabrycky, W. J.(2006) Systemtechnik und Analyse (4. Aufl.) New Jersey: Prentice Hall. S.31
- ^ a b Post, G. & Anderson, D. (2006). Managementinformationssysteme: Geschäftsprobleme mit Informationstechnologie lösen. (4. Aufl.). New York: McGraw-Hill Irwin.
- ^ Blanchard und Fabrycky (2006). Systemtechnik und Analyse, vierte Ausgabe. Prentice Hall. p. 19.
- ^ Dr. Joahn Gouws (2007). Einführung in das Engineering, Systemtechnik. Melikon Pty Ltd.
- ^ Cunningham, James. "HERC -Wartung". Fargo. Xxi (North Avenue): 49. archiviert von das Original am 21. Januar 2013. Abgerufen 13. Mai 2009.
Weitere Lektüre
- Cummings, Haag (2006). Managementinformationssysteme für das Informationsalter. Toronto, McGraw-Hill Ryerson
- Beynon-Davies P. (2009). Wirtschaftsinformatik. Palgrave, Basingstoke. ISBN978-0-230-20368-6
- Computer World, 2002, Abgerufen am 22. Juni 2006 aus dem World Wide Web:
- Management Information Systems, 2005, Abgerufen am 22. Juni 2006 aus dem World Wide Web:
Externe Links
- Der Lebenszyklus der agilen Systementwicklung
- Pension Benefit Guaranty Corporation - Informationstechnologie Solutions Lifecycle -Methodik
- Dod integriertes Framework -Diagramm IFC (Vorderseite, der Rücken)
- FSA Life Cycle Framework
- HHS Enterprise Performance Life Cycle Framework
- Der Lebenszyklus für offene Systeme Entwicklungszyklus
- Modellierung des Systementwicklungszyklus Evolution
- Lebenszyklus null Abweichung
- Integrierte Verteidigung AT & L Life Cycle Management -Diagramm, die US -amerikanische DOD -Form dieses Konzepts.