Struktureller Ansatz. Systemansatz in der Softwareentwicklung. Zeitliche und "räumliche" Aspekte des Systemansatzes. Wasserfall-Softwarelebenszyklusmodell Ansätze zur Softwareentwicklung
1. Cascade (englischer Wasserfall) - Standardentwicklungsmodell
Kaskadenentwicklungsmodell - ein Modell, bei dem alle Entwicklungsstufen nacheinander durchgeführt werden - die nächste Stufe beginnt, nachdem die vorherige abgeschlossen ist.
Dieses Modell umfasst die folgenden Schritte im Softwareentwicklungsprozess:
Zunächst wird bestimmt technische Spezifikationen zukünftiges Programm, als Ergebnis wird eine Liste der Softwareanforderungen genehmigt. Als nächstes kommt der Übergang zum Design, bei dem eine Dokumentation erstellt wird, die Programmierern einen Plan und eine Möglichkeit zur Umsetzung der Anforderungen beschreibt.
Nachdem das Design abgeschlossen ist, implementieren (konstruieren) die Programmierer das Projekt. In der Umsetzungsphase werden alle Projektkomponenten integriert. Erst nach dem vollständigen Abschluss dieser Phasen erfolgt das Testen und Debuggen des fertigen Produkts. Weiterhin kann das Softwareprodukt implementiert werden und nach der Implementierung Unterstützung bieten – neue Funktionalität einführen und Fehler beseitigen.
Die Hauptvorteile der Wasserfallentwicklung:
2. Agile Softwareentwicklungsmethodik
Eine Reihe von Entwicklungsmethoden Software Bereitstellung gemeinsame Arbeit Vertreter der Kunden und Entwickler. Die agile Entwicklungsmethode basiert auf einem iterativen Vorgehen, der dynamischen Anforderungsbildung und deren Umsetzung in kurzen Etappen.
Das Ergebnis jeder dieser Phasen, einschließlich eines Zyklus von Iterationen, ist ein Miniatur-Softwareprojekt,
Es gibt mehrere agile Entwicklungsmethoden, die bekanntesten sind Scrum, Extreme Programming, DSDM.
Die wichtigsten Vorteile der agilen Entwicklung:
| Risikominimierung; schrittweise Erhöhung der Funktionalität Softwareprodukt; eine kleine Menge schriftlicher Dokumentation; Start der Basisversion des Programms so schnell wie möglich. | |||
Es gibt auch Nachteile: |
|||
| die Unfähigkeit, das Projektbudget genau zu bestimmen; die Unmöglichkeit, den genauen Zeitpunkt der Projektbereitschaft zu bestimmen; nicht geeignet für Staats- und Haushaltsorganisationen; erfordert Motivation von verantwortlichen Vertretern des Kunden. | |||
Manifest der agilen SoftwareentwicklungWir entdecken ständig bessere Möglichkeiten, Software zu entwickeln, indem wir direkt entwickeln und anderen helfen. Dank der geleisteten Arbeit konnten wir Folgendes feststellen: Menschen und Interaktion wichtiger als Prozesse und Tools Funktionierendes Produkt wichtiger als eine umfassende Dokumentation Zusammenarbeit mit dem Kunden wichtiger als Vertragsverhandlungen Viel wichtiger ist die Bereitschaft zur Veränderung nach dem ursprünglichen Plan Das heißt, ohne die Wichtigkeit dessen zu leugnen, was rechts ist, schätzen wir immer noch mehr, was links ist. |
Agile Entwicklungsprinzipien:
|
Kundenzufriedenheit durch schnelle und unterbrechungsfreie Lieferung der notwendigen Software; |
Im ersten Teil haben wir uns entschieden, Softwareentwicklungsmethoden wie Indikatoren wie das Verhältnis von Methodik zu iterativer Entwicklung und den Grad der Formalität bei der Gestaltung von Arbeitsmaterialien und allgemein bei der Entwicklung zu vergleichen. In diesem Teil verwenden wir diese Metriken, um die bekanntesten Softwareentwicklungspraktiken zu vergleichen.
Wir werden sehen, wie es weitergeht…
Leider ist dies die am schwierigsten zu beschreibende Kategorie - schließlich umfasst sie sowohl das Produkt des krampfhaften Werfens eines Anfängers, der versucht, sein erstes Projekt um jeden Preis abzuschließen, als auch ziemlich ausgereifte und etablierte Methoden, die viele Jahre in Anspruch genommen haben von und vielfältigen Erfahrungen bestimmter Entwicklungsteams und sogar in internen Vorschriften beschrieben. Da Personen, die in der Lage sind, ihre eigene Methodik zu entwickeln, diese in der Regel selbst hinsichtlich Iteration und Formalisierung bewerten können, konzentrieren wir uns auf Anfänger. Leider bedeutet dies meistens, dass die Regeln für die Durchführung der Entwicklung entweder gar nicht existieren oder entwickelt und verabschiedet wurden, aber nicht umgesetzt werden. Natürlich unter solchen Bedingungen ist extrem niedriges Niveau Entwicklungsformalismus. Das ist also alles klar.
Entwicklung "Wie es funktioniert"
Wie wäre es mit einem iterativen Vorgehen? Leider wird es in der Regel in solchen Projekten nicht verwendet. Erstens, weil es schon bei den ersten Iterationen erlauben würde, das Projekt als äußerst zweifelhaft zu bewerten und das dringende Eingreifen des höheren Managements zu erfordern, um die Ordnung wiederherzustellen. Schließlich gilt in einem iterativen Projekt die traditionelle Antwort des Programmierers, dass alles zu 90 % für ihn bereit ist, nur bis zum Abschluss der ersten Iteration…
Strukturelle Methoden
Strukturelle Methoden
Strukturelle Methoden sind eine Gruppe von Methoden, die in der Regel noch vor der weit verbreiteten Verwendung objektorientierter Sprachen entwickelt wurden. Alle beinhalten eine Wasserfallentwicklung. Obwohl, wie sich herausstellte, bereits in diesem Artikel, der oft als erste Präsentation des Wasserfallansatzes zitiert wird, gesagt wurde, dass es wünschenswert ist, das Projekt mit der Entwicklung eines Prototyps zu beginnen, dh zumindest durchzuführen zwei Iterationen.
Grundlage dieser Methoden ist jedoch der sequentielle Übergang von Arbeit zu Arbeit und die Weitergabe der Ergebnisse (Dokumente) der nächsten Stufe an die Teilnehmer der nächsten Stufe.
Auch gehen alle diese Methoden von einem stark formalisierten Ansatz aus, obwohl sich in ihnen Aussagen über einen angemessenen Dokumentationsumfang finden lassen. Eines der nicht offensichtlichen Beispiele dafür, dass sich Softwareentwicklungsmethoden nicht nur im Westen entwickelt haben, ist ein Zitat aus einem Anfang der 1980er Jahre in unserem Land veröffentlichten Buch, das besagt, dass der Grad der Formalisierung einer Programmieraufgabe basierend bestimmt werden sollte darauf, wie gut der Analyst und Programmierer. Und das, obwohl das Thema des Buches die Entwicklung ganz kritischer, wie man sie heute nennt, Systeme betraf, deren Fehler zu schweren Verlusten oder gar Katastrophen führen.
Agile Methoden
Agile Methoden basieren auf zehn Prinzipien, von denen wir nur diejenigen nennen werden, die die Bewertung dieser Methoden nach den ausgewählten Parametern bestimmen:
- die Hauptsache ist, den Kunden zufriedenzustellen und ihm das Produkt so schnell wie möglich zur Verfügung zu stellen;
- Neue Versionen des Produkts sollten alle paar Wochen erscheinen, im Extremfall - Monate;
- am meisten effektive Methode Wissenstransfer zu den Entwicklungsbeteiligten und zwischen ihnen - persönliche Kommunikation;
- Ein laufendes Programm ist der beste Indikator für den Entwicklungsfortschritt.
Daher sind diese Methoden klar auf iterative Softwareentwicklung und minimale Formalisierung des Prozesses ausgerichtet. Zum zweiten Punkt muss jedoch ein Vorbehalt gemacht werden: Diese Methoden konzentrieren sich auf das Mindestmaß an Formalisierung, das für ein bestimmtes Projekt akzeptabel ist. Mindestens eine der in der flexiblen Gruppe enthaltenen Methoden - Crystal - weist Modifikationen auf, die darauf ausgelegt sind, Prozesse mit einer unterschiedlichen Anzahl von Teilnehmern und einer unterschiedlichen Kritikalität der entwickelten Software durchzuführen (die Kritikalität der Software wird durch die möglichen Folgen von Fehlern bestimmt, die von geringfügig abweichen können finanzielle Verluste durch die Behebung eines Fehlers bis hin zu einem katastrophalen Fehler). Damit ein weiterer Vergleich mit flexiblen Methoden nicht sinnlos ist, stellen wir vor kurze Beschreibungen Einige von ihnen.
eXtreme Programming oder XP (Extreme Programming)
Die von Kent Beck, Ward Cunningham und Ron Jeffries entwickelte XP-Methodik ist heute die bekannteste der agilen Methoden. Manchmal wird das Konzept „agile Methodologien“ explizit oder implizit mit XP identifiziert, das Geselligkeit, Einfachheit, Rückmeldung und Mut. Es wird als eine Reihe von Praktiken beschrieben: Planungsspiel, Kurzversionen, Metaphern, einfaches Design, Code-Refactoring (Refactoring), Test-Ahead-Entwicklung, Paarprogrammierung, kollektives Eigentum an Code, 40-Stunden-Woche, ständige Kundenpräsenz und Code-Standards. Das Interesse an XP wuchs von unten nach oben – von Entwicklern und Testern, die von schmerzhaften Prozessen, Dokumentationen, Metriken und anderen Formalismen gequält wurden. Sie lehnten Disziplin nicht ab, wollten sich aber nicht sinnlos an formale Vorgaben halten und suchten nach neuen schnellen und flexiblen Ansätzen zur Entwicklung qualitativ hochwertiger Programme.
Beim Einsatz von XP wird die sorgfältige Vorplanung der Software einerseits durch die ständige Präsenz des Kunden im Team ersetzt, der bereit ist, jede Frage zu beantworten und jeden Prototypen zu evaluieren, und andererseits durch regelmäßige Code-Revisionen (sog Refactoring). Gründlich kommentierter Code gilt als Grundlage der Designdokumentation. In der Methodik wird dem Testen viel Aufmerksamkeit geschenkt. In der Regel wird für jede neue Methode zunächst ein Test geschrieben und dann der eigentliche Methodencode entwickelt, bis der Test erfolgreich läuft. Diese Tests werden in Suiten gespeichert, die nach jeder Codeänderung automatisch ausgeführt werden.
Während Pair Programming und die 40-Stunden-Woche vielleicht die bekanntesten Merkmale von XP sind, sind sie dennoch hilfreich und unterstützend. Hochleistung Entwickler und Reduzierung der Anzahl von Entwicklungsfehlern.
Kristallklar
Crystal ist eine Familie von Methoden, die den erforderlichen Formalisierungsgrad des Entwicklungsprozesses in Abhängigkeit von der Anzahl der Teilnehmer und der Kritikalität der Aufgaben bestimmen.
Die Crystal-Clear-Methode ist XP in Bezug auf die Leistung unterlegen, aber sie ist so einfach wie möglich zu verwenden. Es erfordert nur minimalen Aufwand für die Implementierung, da es sich auf menschliche Gewohnheiten konzentriert. Es wird angenommen, dass diese Methodik die natürliche Ordnung der Softwareentwicklung beschreibt, die in ausreichend qualifizierten Teams etabliert wird, wenn sie sich nicht mit der zielgerichteten Umsetzung einer anderen Methodik beschäftigen.
Hauptmerkmale von Crystal Clear:
- iterative inkrementelle Entwicklung;
- automatische Regressionstests;
- die Benutzer beteiligen sich aktiv am Projekt;
- die Zusammensetzung der Dokumentation wird von den Projektbeteiligten bestimmt;
- In der Regel werden Tools zur Code-Versionskontrolle verwendet.
Neben Crystal Clear gibt es mehrere andere Methoden in der Crystal-Familie, die für größere oder kritischere Projekte entwickelt wurden. Sie unterscheiden sich durch etwas strengere Anforderungen an den Dokumentationsumfang und unterstützende Verfahren wie Änderungs- und Versionskontrolle.
Feature-gesteuerte Entwicklung
Feature Driven Development (FDD) arbeitet in Bezug auf eine Systemfunktion oder eine Funktion, die dem RUP-Anwendungsfallkonzept ziemlich nahe kommt. Der vielleicht bedeutendste Unterschied ist eine zusätzliche Einschränkung: "Jede Funktion muss eine Implementierung in maximal zwei Wochen ermöglichen." Das heißt, wenn der Anwendungsfall klein genug ist, kann er als Funktion betrachtet werden, und wenn er groß ist, sollte er in mehrere relativ unabhängige Funktionen zerlegt werden.
FDD umfasst fünf Prozesse, wobei die letzten beiden für jedes Merkmal wiederholt werden:
- Entwicklung allgemeines Modell;
- Auflistung notwendige Funktionen Systeme;
- Planung der Arbeit an jeder Funktion;
- Funktionsdesign;
- Funktionsaufbau.
Die Arbeit am Projekt umfasst häufige Builds und ist in Iterationen unterteilt, von denen jede mit einem bestimmten Satz von Funktionen implementiert wird.
Entwickler in FDD werden in „Klassenmeister“ und „Chefprogrammierer“ unterteilt. Die Hauptprogrammierer beziehen die Eigentümer der beteiligten Klassen mit ein, um an der nächsten Eigenschaft zu arbeiten. Zum Vergleich: In XP gibt es keine persönlich verantwortlichen Klassen oder Methoden.
Gemeinsamkeiten
Die Liste der flexiblen Methoden ist derzeit ziemlich lang. Dennoch vermitteln die von uns beschriebenen Methoden ein sehr vollständiges Bild der gesamten Familie.
Fast alle agilen Methoden verwenden einen iterativen Ansatz, bei dem nur ein begrenzter Arbeitsaufwand für die Veröffentlichung des nächsten Releases im Detail geplant wird.
Fast alle agilen Methoden konzentrieren sich auf den informellsten Entwicklungsansatz. Wenn das Problem im Laufe eines normalen Gesprächs gelöst werden kann, ist es besser, genau das zu tun. Und aufzuziehen Entscheidung in Papierform bzw elektronisches Dokument nur dann notwendig, wenn darauf nicht verzichtet werden kann.
Agile Methoden
GOSTs
GOSTs sind, wie die im nächsten Abschnitt beschriebenen CMM-Anforderungen, keine Methoden. Sie beschreiben in der Regel nicht die Softwareentwicklungsprozesse selbst, sondern formulieren lediglich bestimmte Anforderungen an die Prozesse, denen verschiedene Methodiken mehr oder weniger entsprechen. Der Vergleich von Anforderungen nach den gleichen Kriterien, nach denen wir Methoden vergleichen, hilft Ihnen, sofort zu entscheiden, welche Methoden Sie verwenden sollten, wenn Sie in Übereinstimmung mit GOST entwickeln müssen.
Derzeit gelten in Russland die alten GOSTs der 19. und 34. Reihe und die neuere GOST R ISO IEC 122207. Die GOSTs der 19. und 34. Reihe sind strikt auf den Kaskadenansatz in der Softwareentwicklung ausgerichtet. Die Entwicklung gemäß diesen GOSTs erfolgt in Phasen, von denen jede die Ausführung streng definierter Arbeiten umfasst, und endet mit der Veröffentlichung einer relativ großen Anzahl sehr formalisierter und umfangreicher Dokumente. Somit führt die sofortige strikte Einhaltung dieser Standards nicht nur zu einem Wasserfallansatz, sondern auch zu einem sehr hohen Formalisierungsgrad der Entwicklung.
GOST-Anforderungen
GOST 12207 beschreibt im Gegensatz zu den Standards der 19. und 34. Reihe die Softwareentwicklung als eine Reihe von Haupt- und Hilfsprozessen, die vom Anfang bis zum Ende des Projekts ausgeführt werden können. Modell Lebenszyklus können je nach Projektspezifika ausgewählt werden. Daher verbietet dieses GOST die Verwendung eines iterativen Ansatzes nicht ausdrücklich, empfiehlt jedoch seine Verwendung nicht ausdrücklich. GOST 12207 ist auch flexibler in Bezug auf Anforderungen an die Formalität des Entwicklungsprozesses. Es enthält nur Hinweise auf die Notwendigkeit, die wesentlichen Ergebnisse aller Prozesse zu dokumentieren, enthält jedoch keine Listen erforderlicher Dokumente und Anweisungen zu deren Inhalt.
Somit ermöglicht GOST 12207 eine iterative und weniger formalisierte Softwareentwicklung.
Entwicklungsprozess-Reifegradmodelle (CMM, CMMI)
Neben Regierung u internationale Standards gibt es mehrere Ansätze zur Zertifizierung des Entwicklungsprozesses. Die bekanntesten von ihnen in Russland sind anscheinend CMM und CMMI.
CMM (Capability Maturity Model) ist ein Reifegradmodell von Softwareentwicklungsprozessen, das den Reifegrad des Entwicklungsprozesses in einem bestimmten Unternehmen beurteilen soll. Nach diesem Modell gibt es fünf Reifegrade des Entwicklungsprozesses. Die erste Ebene entspricht der „How it goes“-Entwicklung, wenn Entwickler jedes Projekt als Leistung angehen. Die zweite entspricht mehr oder weniger etablierten Prozessen, wenn man mit hinreichender Sicherheit mit einem positiven Ergebnis des Projekts rechnen kann. Die dritte entspricht dem Vorhandensein entwickelter und gut beschriebener Prozesse, die bei der Entwicklung verwendet werden, und die vierte entspricht der aktiven Verwendung von Metriken im Managementprozess, um Ziele zu setzen und deren Erreichung zu überwachen. Die fünfte Ebene schließlich bezieht sich auf die Fähigkeit des Unternehmens, den Prozess bei Bedarf zu optimieren.
CMM- und CMMI-Anforderungen
Nach dem Aufkommen von CMM begann man, spezialisierte Reifegradmodelle zu entwickeln Informationssysteme, für den Prozess der Lieferantenauswahl und einige andere. Darauf aufbauend wurde ein integriertes CMMI-Modell (Capability Maturity Model Integration) entwickelt. Darüber hinaus wurde in CMMI versucht, die bis dahin manifestierten Mängel von CMM zu überwinden - eine Übertreibung der Rolle formaler Beschreibungen von Prozessen, als das Vorhandensein einer bestimmten Dokumentation viel höher bewertet wurde als nur eine gut etablierte, aber nicht beschriebener Prozess. CMMI konzentriert sich jedoch auch auf die Verwendung eines stark formalisierten Prozesses.
Die Grundlage der CMM- und CMMI-Modelle ist somit die Formalisierung des Entwicklungsprozesses. Sie zielen Entwickler auf die Implementierung eines in den Vorschriften und Anweisungen detailliert beschriebenen Prozesses ab, was wiederum die Entwicklung einer großen Menge an Projektdokumentation für eine angemessene Kontrolle und Berichterstattung erfordern kann.
Die Beziehung von CMM und CMMI zur iterativen Entwicklung ist eher indirekt. Formal stellt keiner von ihnen spezifische Anforderungen für die Einhaltung eines Wasserfall- oder iterativen Ansatzes. Einigen Experten zufolge ist CMM jedoch besser mit dem Wasserfallansatz kompatibel, während CMMI auch einen iterativen Ansatz ermöglicht.
RUP
Natürlich ist RUP eine iterative Methodik. Obwohl formal die obligatorische Ausführung aller Phasen oder eine Mindestanzahl von Iterationen nirgendwo in RUP angegeben ist, konzentriert sich der gesamte Ansatz darauf, dass es ziemlich viele davon gibt. Aufgrund der begrenzten Anzahl von Iterationen können Sie RUP nicht voll ausnutzen. Gleichzeitig kann RUP auch in fast kaskadierenden Projekten verwendet werden, die wirklich nur ein paar Iterationen umfassen: eine in der Build-Phase und die andere in der Transfer-Phase. Übrigens ist dies die Anzahl der Iterationen, die tatsächlich in Wasserfallprojekten verwendet wird. Der Test und der Probebetrieb des Systems beinhalten schließlich Korrekturen, die bestimmte Aktionen in Bezug auf Analyse, Design und Entwicklung beinhalten können, dh sie sind ein weiterer Durchgang durch alle Phasen der Entwicklung.
RUP-Methodik
Hinsichtlich der Formalität der Methodik bietet RUP dem Anwender ein sehr breites Spektrum an Möglichkeiten. Wenn Sie alle Arbeiten und Aufgaben erledigen, alle Artefakte erstellen und ziemlich formell (mit einem offiziellen Gutachter, mit der Vorbereitung einer vollständigen Überprüfung in Form eines elektronischen oder Papierdokuments usw.) alle Überprüfungen durchführen, kann RUP sich umdrehen sich als eine äußerst formale, schwerfällige Methodik herausstellt. Gleichzeitig ermöglicht Ihnen RUP, nur die Artefakte zu entwickeln und nur die Arbeiten und Aufgaben auszuführen, die in einem bestimmten Projekt erforderlich sind. Und ausgewählte Artefakte können mit einem beliebigen Grad an Formalität ausgeführt und überprüft werden. Es ist möglich, ein detailliertes Studium und eine sorgfältige Ausführung jedes Dokuments, die Bereitstellung einer ebenso sorgfältig durchgeführten und formalisierten Überprüfung zu verlangen und sogar, der alten Praxis folgend, jede solche Überprüfung vom wissenschaftlichen und technischen Rat des Unternehmens zu genehmigen. Kannst du einschränken Email oder auf Papier skizzieren. Darüber hinaus gibt es immer noch eine Möglichkeit: sich ein Dokument im Kopf zu bilden, also über das relevante Thema nachzudenken und eine konstruktive Entscheidung zu treffen. Und wenn diese Entscheidung nur Sie betrifft, dann beschränken Sie sich zum Beispiel auf einen Kommentar im Programmcode.
Somit ist RUP eine iterative Methodik mit einer sehr großen Bandbreite mögliche Lösungen im Hinblick auf die Formalisierung des Entwicklungsprozesses.
Fassen wir den zweiten Teil des Artikels zusammen. RUP erlaubt im Gegensatz zu den meisten anderen Methoden große Auswahl Wählen Sie den Grad der Formalisierung und Iteration des Entwicklungsprozesses in Abhängigkeit von den Eigenschaften der Projekte und der sich entwickelnden Organisation.
Und warum das so wichtig ist – darauf gehen wir im nächsten Teil ein.
Nun gibt es in der Softwaretechnik zwei Hauptansätze für die Entwicklung von IP-Software, deren grundlegender Unterschied darauf zurückzuführen ist verschiedene Wege Systemzerlegung: funktional-modularer (struktureller) Ansatz, der auf dem Prinzip der funktionalen Zerlegung beruht, bei dem die Struktur des Systems in Bezug auf die Hierarchie seiner Funktionen und den Informationstransfer zwischen einzelnen Funktionselementen beschrieben wird, und objektorientierter Ansatz, die Objektzerlegung verwendet, beschreibt die Struktur des IS in Bezug auf Objekte und Beziehungen zwischen ihnen und das Verhalten des Systems in Bezug auf die Nachrichtenübermittlung zwischen Objekten.
Die Essenz des strukturellen Ansatzes zur Entwicklung von IS-Software liegt also in seiner Zerlegung in automatisierte Funktionen: Das System wird in funktionale Subsysteme unterteilt, die wiederum in Unterfunktionen unterteilt werden, sie werden in Aufgaben unterteilt und so weiter bis zu spezifischen Verfahren. Gleichzeitig bewahrt IS die Integrität der Darstellung, bei der alle Komponenten miteinander verbunden sind. Bei der Entwicklung eines Systems „von unten“, von einzelnen Aufgaben bis hin zum Gesamtsystem, geht die Integrität verloren, es entstehen Probleme bei der Beschreibung des Informationszusammenspiels einzelner Komponenten.
Die Grundprinzipien des strukturellen Ansatzes sind:
o Prinzip " Teile und herrsche";
o Prinzip hierarchische Ordnung - das Prinzip der Organisation von Komponentensystemen in hierarchischen Baumstrukturen mit dem Hinzufügen neuer Details auf jeder Ebene. Die Auswahl von zwei Grundprinzipien bedeutet nicht, dass die verbleibenden Prinzipien zweitrangig sind, da das Ignorieren eines von ihnen zu unvorhersehbaren Konsequenzen führen kann.
Die wichtigsten dieser Prinzipien sind:
o Abstraktion - Hervorhebung der wesentlichen Aspekte des Systems;
o Konsistenz - Gültigkeit und Kohärenz der Elemente des Systems;
o Datenstrukturierung - Daten sollten strukturiert und hierarchisch organisiert sein.
Methodische Grundlagen von Softwareentwicklungstechnologien
Visuelle Modellierung. Das Softwaremodell in Allgemeiner Fall bezeichnet eine formalisierte Beschreibung eines Softwaresystems auf einer bestimmten Abstraktionsebene. Jedes Modell definiert einen bestimmten Aspekt des Systems, verwendet eine Reihe von Diagrammen und Dokumenten in einem bestimmten Format und spiegelt die Gedanken und Aktivitäten verschiedener Personen mit bestimmten Interessen, Rollen oder Aufgaben wider.
Grafische (visuelle) Modelle sind Werkzeuge zur Visualisierung, Beschreibung, Gestaltung und Dokumentation der Systemarchitektur. Die Zusammensetzung der im konkreten Projekt verwendeten Modelle und der Detaillierungsgrad im allgemeinen Fall hängen von folgenden Faktoren ab:
o die Schwierigkeiten des entworfenen Systems;
o die notwendige Vollständigkeit seiner Beschreibung;
o Kenntnisse und Fähigkeiten der Projektteilnehmer;
o Zeit, die für das Design vorgesehen ist.
Die visuelle Modellierung hat insbesondere die Entwicklung von CASE-Tools stark beeinflusst. Der Begriff CASE (Computer Aided Software Engineering) wird im weitesten Sinne verwendet. Die ursprüngliche Bedeutung dieses Konzepts, das nur auf die Aufgaben der Automatisierung der Softwareentwicklung beschränkt war, hat nun eine neue Bedeutung erlangt, die die meisten Prozesse des Softwarelebenszyklus abdeckt.
Die CASE-Technologie ist eine Reihe von Softwaredesignmethoden sowie eine Reihe von Werkzeugen, mit denen Sie einen Themenbereich visuell modellieren, dieses Modell in allen Phasen der Softwareentwicklung und -wartung analysieren und eine Anwendung entsprechend entwickeln können Informationsbedarf Benutzer. Die meisten existierenden CASE-Tools basieren auf strukturellen oder objektorientierten Analyse- und Entwurfsmethoden, die Spezifikationen in Form von Diagrammen oder Texten verwenden, um externe Anforderungen, Beziehungen zwischen Systemmodellen, Systemverhaltensdynamiken und Softwarearchitekturen zu beschreiben.
1. Zweck der Programmiertechnik. Die Entwicklungsgeschichte der Programmiertechnik. Arten von Softwareprojekten. Komponenten der Programmiertechnik. Projekt, Produkt, Prozess und Menschen
2. Lebenszyklus des Programms. Die zyklische Natur der Entwicklung. Grundbegriffe der Programmiertechnik. Prozesse und Modelle. Phasen und Wendungen. Meilensteine und Artefakte. Stakeholder und Mitarbeiter.
3. Identifizierung und Analyse von Anforderungen. Software Anforderungen. Anforderungsentwicklungsschema. Anforderungsmanagement.
4. Architektonisches und detailliertes Design. Implementierung und Codierung. Testen und Verifizieren . Qualitätskontrollprozess. White-Box- und Black-Box-Methoden. Inspektion und Bewertungen. Ziele testen. Verifizierung, Validierung und Systemtests. Wartung und Weiterentwicklung.
5. Entwicklungsprozessmodelle. Wasserfall- und Förderermodelle. Spiral- und inkrementelle Modelle. Flexible Entwicklungsprozessmodelle.
6. Entwerfen eines Prozessmodells. Identifizierung von Prozessanforderungen. Verwendete Phasen, Meilensteine und Artefakte. Wahl der Prozessarchitektur. Das Verfahren zur Durchführung eines typischen Projekts. dokumentierte Verfahren.
7. Modelle des Entwicklungsteams. Die kollektive Natur der Entwicklung. Optimale Teamgröße. Unterordnung der Projektbeteiligten. Teamentwicklung und Personalentwicklung. Spezialisierung, Kooperation und Interaktion.
8. Modelle des Entwicklungsteams. Hierarchisches Teammodell. Die OP-Team-Methode. Modell eines Teams auf Augenhöhe.
9. Die Art der Programmierung. Wissenschaft der Programmierung. Die Kunst des Programmierens. Das Handwerk des Programmierens. Programmierparadigmen. Strukturelle Programmierung. Logische Programmierung. Objekt orientierte Programmierung.
10. Softwarearchitektur. Veranstaltungsmanagement. Client/Server-Architektur. Dienstleistungen. dreischichtige Architektur. Programmdesign. Konzeptentwicklung. Logikdesign. Detailliertes Design.
1. Novikov-Ansätze zur Softwareentwicklung“ http://window. /window_catalog/files/r60368/itmo307.pdf.
2. Extreme Programmierung. - Sankt Petersburg: Peter, 2002.
3. Softwareentwicklungstechnologie. - St. Petersburg. : Peter, 2004.
4. Brooks Jr. entworfen und erstellt Softwarekomplexe. Moskau: Nauka, 1975; neue Übersetzungsausgabe: Mythischer Mannmonat. Sankt Petersburg: SYMBOL+, 1999.
5. Algorithmen + Datenstrukturen = Programme. M., Mir, 1978.
6. Systematische Programmierung. Einführung. M.: Mir, 1977.
7. Strukturierte Programmierung. M.: Mir, 1975.
8. Programmierdisziplin. M.: Mir, 1978.
9. Softwareentwicklungstechnologien. - Sankt Petersburg: Peter, 2002.
10. Terekhov-Programmierung. M.: BINOM, 2006.
11. Rambo J. Einheitlicher Softwareentwicklungsprozess. Sankt Petersburg: Peter, 2002.
Wirtschaftstheorie für Manager
Grundlegende mikroökonomische Theorien. Anwendungsbeispiele in der Analyse wirtschaftlicher Prozesse. Grundlegende makroökonomische Theorien. Anwendungsbeispiele in der Analyse wirtschaftlicher Prozesse. Prinzipien und Methoden der Steuerung wirtschaftlicher Prozesse. Werkzeuge zur Beurteilung des Entwicklungsstandes wirtschaftlicher Prozesse Probleme der erweiterten Reproduktion. Faktoren des Wirtschaftswachstums der russischen Wirtschaft. Kriterien und Indikatoren nachhaltiger Entwicklung. Glättung zyklischer Schwankungen. Die Rolle des Multiplikators und Beschleunigers bei der Einschätzung des Tempos der wirtschaftlichen Entwicklung. Produktionsfunktionen in der Wirtschaft. Anwendungsbeispiele in der Analyse wirtschaftlicher Prozesse. Profitieren. Berechnung ergebniswirksamer Kennziffern, grafische Darstellung der Gewinnschwelle. Methodik für die Umsetzung der Anlagepolitik.Ein Kurs in Wirtschaftstheorie: ein Lehrbuch für Universitäten / Ed. . -Kirov: "ACA", 2004. Kolemaev - mathematische Modellierung. Modellierung makroökonomischer Prozesse und Systeme: Lehrbuch. M.: UNITY-DANA, 2005. Bazhin-Kybernetik. Kharkiv: Konsul, 2004. Leushin-Workshop über Methoden der mathematischen Modellierung: Lehrbuch. Staat Nischni Nowgorod Technik. univ. - N. Novorod, 2007. Politiker über die Wirtschaft: Vorlesungen von Wirtschaftsnobelpreisträgern. Moskau: Moderne Wirtschaft und Recht, 2005. Cheremnykh. Fortgeschrittenes Niveau: Lehrbuch.-M.:INFRA-M, 2008. Die Entwicklung von Mini-Economy-Institutionen. Wirtschaftsinstitut der Uraler Abteilung der Russischen Akademie der Wissenschaften, - M.: Nauka, 2007.
Technologien für die Entwicklung und Annahme von Managemententscheidungen [N]
Entscheidungsfindung ist die Grundlage der Tätigkeit einer Führungskraft. Einführung in die Entscheidungstheorie. Grundbegriffe der Entscheidungstheorie. Unternehmensführungsmodelle und ihre Auswirkungen auf die Entscheidungsfindung. Verschiedene Wege Klassifizierung von Lösungen. Einteilungen: nach Formalität, nach Routine, nach Häufigkeit, nach Dringlichkeit, nach Zielerreichungsgrad, nach Methode der Alternativwahl. Grundlegende Entscheidungsmethoden. Volitionale Methoden der Entscheidungsfindung. Entscheidungsziele. Zeit, Lösungen zu finden. Grundlegende Fehler Mathematische Methoden der Entscheidungsfindung. Mathematische Aspekte der Entscheidungstheorie. Unternehmensforschung. Mathematischer Ansatz zur Entscheidungsfindung. Entscheidungsbaum. Modelle der Entwicklung und Entscheidungsfindung. Spieltheorie. Mathematische Methoden der Entscheidungsfindung. Mathematische Aspekte der Entscheidungstheorie. Modelle der Warteschlangentheorie. Bestandsverwaltungsmodelle. Lineares Programmiermodell. Transportaufgaben. Simulationsmodellierung. Netzwerkanalyse. Wirtschaftliche Analyse. Grenzen rationaler Modelle. Merkmale der Entwicklung und Entscheidungsfindung in einer Gruppe. Eine Methode zur Bestimmung des Gruppenzusammenhalts basierend auf dem Grad der Verbundenheit von Mengen. Methoden, um eine kollektive Entscheidung zu treffen. Konsensverfahren. Abstimmungsmethoden. Kreative Methoden der Entscheidungsfindung. Brainstorming. Ideenkonferenz. Schiffsrat. Die Mental-Hats-Methode von de Bono. Theorie des erfinderischen Problemlösens (TRIZ). Die ideale Endlösung. Beispiele für Probleme und deren Lösung mit TRIZ. Anwendung der TRIZ-Methoden, um einzigartige und kreative Entscheidungen zu treffen. Methoden zur Entwicklung von Lösungsideen und deren Anpassung an die Situation. Zielbaummodell. Die Strategie der Koordinierung der Interessen. Entscheidungsfindung zur Interessenkoordinierung. Methoden zur Bestimmung der Interessen von Gegenparteien. Entscheidungsunterstützungssysteme (Expertensysteme). Die Entstehungsgeschichte von Entscheidungssystemen. Klassifizierung von Entscheidungssystemen. Typischer Aufbau eines Expertensystems. Wege der Wissensrepräsentation. Methoden des logischen Schließens. Anwendung Expertensysteme auf die Praxis.I. Theorie der Entscheidungsfindung: Lehrbuch. - M.: Klausur, 2006. - 573 S. I. Entscheidungsfindung. Theorie und Methoden der Entwicklung von Managemententscheidungen. Lernprogramm. - M.: März 2005. - 496 S. Entwicklung einer Managemententscheidung - M.: Delo-Verlag, 2004 - 392 S. G. Gutachten und Entscheidungsfindung - M.: Patent, 1996. - 271 p. Taha // Einführung in das Operations Research = Operations Research: Eine Einführung. - 7. Aufl. - M.: "Williams", 2007. - S. 549-594. G.Theil. Wirtschaftsprognosen und Entscheidungsfindung. M.: Progress, 1970. K. D. Lewis. Methoden zur Prognose von Wirtschaftsindikatoren. M.: "Finanzen und Statistik" 1986. G. S. Kildishev, A. A. Frenkel. Zeitreihenanalyse und Prognose. M.: "Statistics" 1973. O. Kim, C. W. Muller, W. R. Klekka et al. Faktor-, Diskriminanz- und Clusteranalyse. M.: "Finanzen und Statistik" 1989. Effektiver Manager. Buch 3. Entscheidungsfindung. - MIM LINK, 1999 Turevsky und die Leitung eines Kraftverkehrsunternehmens. - M .: Gymnasium, 2005.,; ed. . Systemanalyse im Management: Lernprogramm. - M.: Finanzen und Statistik, 2006. , Tinkov: Lehrbuch. – M.: KNORUS, 2006.
Modellierung von Geschäftsprozessen in integrierten Managementsystemen
Was sind die Prinzipien von Geschäftsprozessen? Was ist das Problem einer ganzheitlichen Beschreibung von Geschäftsprozessen? Was ist ein System, welche Eigenschaften hat es? Die Rolle der Systemanalyse in der Geschäftsprozessmodellierung? Prozess als Objekt der Kontrolle. Prozessumgebung. Grundelemente eines Geschäftsprozesses. Vor- und Nachteile des Funktions- und Prozessmanagements. PDCA-Verwaltungszyklus. Phasen des Prozessmanagementzyklus. PDCA-Zyklus und Umsetzung der Anforderungen von ISO 9001:2008. SADT-Methodik (Structured Analysis and Design Technique - eine Methode der Strukturanalyse und des Entwurfs). Wesen. Grundlegende Bestimmungen. Wie wird das funktionale Aktivitätsmodell in der IDEF0-Methodik dargestellt? Was bedeuten die Arbeiten in den Diagrammen des Funktionsmodells, wie werden sie nach der IDEF0-Methodik dargestellt? Wozu dienen die Pfeile in den Funktionsmodelldiagrammen, was sind ihre Arten und Arten? DFD-Methodik. Wesen. Grundkomponenten von DFD-Karten. Was sind die Eigenschaften von DFD-Diagrammen, was wird darin beschrieben? Was sind die Eigenschaften von DFD-Diagrammobjekten? Was stellen die Pfeile im DFD-Diagramm dar? IDEF3-Methodik. Wesen. Mittel der Dokumentation und Modellierung. Was sind die Merkmale von IDEF3-Diagrammen, was beschreiben sie? Was sind die Funktionen von IDEF3-Diagrammobjekten? Und der Schütze? Klassifizierung von Prozessen. Typische Geschäftsprozesse. Reengineering und seine Technologie. Wann ist Reengineering in der Führung eines Unternehmens sinnvoll? Überwachung und Messung von Prozessen. Indikatoren für die Prozesse der Organisation. Numerische und bewertende Bewertung von Prozessen.„Modellierung von Geschäftsprozessen mit AllFusion Process Modeler (BPwin 4.1) Dialog-MEPhI“ 2003 „Erstellung von Informationssystemen mit AllFusion Modeling Suite“ hrsg. "Dialogue-MEPhI" 2003 "Die Praxis der funktionalen Modellierung mit AllFusion Process Modeler 4.1. (BPwin) Wo? Warum? Wie?" ed. „Dialogue-MEPhI“ 2004 Dubeikovsky-Modellierung mit AllFusion Process Modeler (BPwin). ed. „Dialogue-MEPhI“ 2007 D. Mark, K. McGowan „Methodology of Structural Analysis and Design SADT“ 1993 klassisches Werk zur SADT-Methodik. Cheremnykh Analyse von Systemen: IDEF-Technologien, Modellierung und Analyse von Systemen. IDEF-Technologien. Werkstatt. M.: Finanzen und Statistik, 2001. , „Strukturelle Geschäftsmodelle: DFD-Technologien“ http://www. /Level4.asp? ItemId=5810 „Theorie und Praxis der Geschäftsprozessreorganisation“ 2003/ P50.1.. Methodik der funktionalen Modellierung. Moskau: Gosstandart of Russia, 2000. http://www. IDEF0, IDEF3, DFD http://www. Modellierung von Geschäftsprozessen mit BPwin http://www. /department/se/devis/7/ IDEF0 im Geschäfhttp:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.
Bewertung der Wirksamkeit von Softwareprodukten
1. IT-Architektur
2. Domänen von Managementprozessen.
3. Liste der Prozesse der Domäne Planung und Organisation
4. Liste der Domänenprozesse Erwerb und Implementierung
5. Liste der Prozesse in der Betriebs- und Wartungsdomäne
6. Liste der Prozesse des Bereichs Überwachung und Bewertung
7. Charakterisierung der Ebenen des Prozessreifegradmodells
9. KPI und KGI, ihre Beziehung und ihr Zweck
1. 10. Allgemeine IT-Kontrollen und Anwendungskontrollen. Verantwortungsbereiche und Verantwortlichkeiten von Business und IT.
Cobit 4.1 Russische Ausgabe.
Gesetzliche Regelung der Schaffung und Nutzung von geistigem Eigentum
1. Führen Sie die geistigen Eigentumsrechte an den Ergebnissen der geistigen Tätigkeit auf und legen Sie deren Inhalt offen.
2. Listen Sie die Arten von Verträgen für die Veräußerung des ausschließlichen Rechts auf. Beschreiben Sie jeden dieser Verträge über die Verfügung über das ausschließliche Recht.
4. Beschreiben Sie die wichtigsten Bestimmungen zum rechtlichen Schutz des Computerprogramms als Gegenstand des Urheberrechts.
5. Vergleichen Sie die wichtigsten Bestimmungen zum rechtlichen Schutz der Datenbank als Gegenstand des Urheberrechts und als Gegenstand verwandter Schutzrechte.
6. Beschreiben Sie die Bedingungen für die Patentierbarkeit von Gegenständen von Patentrechten: Erfindungen; nützliche Modelle; industrielle Designs.
7. Erweitern Sie den Inhalt der Kriterien für die Patentierbarkeit der Erfindung: Neuheit; erfinderische Tätigkeit; industrielle Anwendbarkeit.
8. Beschreiben Sie die Bedingungen und das Verfahren zur Erlangung eines Patents für eine Erfindung, ein Gebrauchsmuster oder ein gewerbliches Design sowie die Bedingungen, die die Gültigkeit von Patenten und ihre Dauer gewährleisten.
9. Definieren Sie „Know-how“ und nennen Sie die Bedingungen, unter denen der rechtliche Schutz von Produktionsgeheimnissen entsteht und durchgeführt wird.
10. Führen Sie die geschützten Individualisierungsmittel auf und geben Sie ihre vergleichenden Merkmale an.
1., Geistiges Eigentumsrecht in Russische Föderation, Lehrbuch // M, Prospekt, 2007
2., Immaterialgüterrecht, Lehrbuch // M, RIOR, 2009
Projektmanagement und Softwareentwicklung [R]
Was ist eine Methodik, warum wird sie benötigt? Die allgemeine Struktur der Methodik, die Hauptelemente der Methodik. Prinzipien der Gestaltung einer eigenen Methodik. Beispiele für verschiedene Artefakte, Rollen, Kompetenzen, Randbedingungen. Struktur der Cowburn-Methodik, Metriken der Methodik. Kriterien des Cowburn-Projekts. Auswahlkriterien für die Methodik, Cowburn-Matrix. Projektlebenszyklus. Wasserfall- und iterative Lebenszyklusmodelle. Grenzen der Anwendbarkeit von Wasserfall- und iterativen Modellen. RUP als Beispiel für eine iterative Methodik. Grundlegende RUP-Konzepte, Anwendbarkeitsgrenzen. Die Rolle des Menschen in der Softwareentwicklung. Agile Methoden, Grundprinzipien agiler Methoden. Der Ursprung agiler Methoden. Scrum als Beispiel für eine agile Methodik. Rollen, Artefakte, Aktivitäten in Scrum. Die Grenzen der Anwendbarkeit von Scrum. Extreme Programming (XP) Ideen, Werte, grundlegende Praktiken, Grenzen der Anwendbarkeit. Ähnlichkeiten und Unterschiede zwischen Scrum und XP. Erfassung und Verwaltung von Anforderungen. Grundpraktiken, Begriffe, Prinzipien. Ansätze zur Dokumentation des Projekts und des Produkts, die wichtigsten Arten von Dokumenten. Beispiele für Anforderungsmanagementpraktiken aus den im Kurs besprochenen Methoden. Planung der Softwareentwicklung. Arten von Plänen, Risikomanagement, beliebte Risiken. Beispiele für Entwicklungsplanungspraktiken aus den im Kurs besprochenen Methoden. Testen in der Softwareentwicklung. Das Konzept der Zusammenstellung (Build) eines Softwareprodukts. Grundlegende Prüfmethoden, Begriffe. Beispiele für Testverfahren aus den im Kurs besprochenen Methoden. Das Konzept der Assemblierung (Build), Möglichkeiten zum Speichern von Code, Tools. Zwei Prinzipien für die Organisation der Arbeit mit einem Versionskontrollsystem. Merkmale des Produktfreigabe-/Layoutprozesses für verschiedene Produktkategorien, Praxisbeispiele. Moderne Konzepte der Softwarearchitektur, Mehrebenenarchitekturen, Architekturkriterien. Aufführen notwendige Entscheidungen beim Entwerfen von Software, Ansätze zur Auswahl eines Speichersystems.Kent Beck - Extreme Programming Frederic Brooks - Der mythische Mann-Monat oder wie sie erschaffen werden Softwaresysteme. Tom de Marco - Frist. Ein Roman über Projektmanagement. Tom de Marco, Timothy Lister - Waltzing with Bears. Tom de Marco, Timothy Lister - Der Faktor Mensch_ erfolgreiche Projekte und Teams. Alistair Cowburn - Jedes Projekt hat seine eigene Methodik. Alistair Cowburn - Der Mensch als nichtlineare und wichtigste Komponente in der Softwareentwicklung. Andriy Orlov - Notizen eines Automaten. Berufliches Geständnis. Philip Krachten - Einführung in den Rational Unified Process. Henrik Kniberg - Scrum und XP: Notizen von der Front. Vorlesungspräsentationen
Wasserfallmodell Anforderungsanalyse Design Implementierung Integration Testen Produktspezifikationsentwurf Produktarchitekturentwurf Quellcodeentwicklung Integration von Quellcodeteilen Testen und Fehlerbehebung
Das Unified Software Development Process (USDP) Use Case Model beschreibt die Fälle, in denen eine Anwendung verwendet wird. Das analytische Modell beschreibt die Basisklassen für die Anwendung. Das Entwurfsmodell beschreibt die Verbindungen und Beziehungen zwischen Klassen und dedizierten Objekten.Das Bereitstellungsmodell beschreibt die Verteilung von Software über Computer. Das Implementierungsmodell beschreibt die interne Organisation Programmcode. Das Testmodell besteht aus Testkomponenten, Testverfahren und verschiedenen Testfällen.
Typische Komponenten der Softwareproduktarchitektur und typische Softwareanforderungen Programmorganisation Hauptsystemklassen Datenorganisation Geschäftsregeln Benutzerschnittstelle Ressourcenverwaltung Sicherheit Leistung Skalierbarkeit Interaktion mit anderen Systemen (Integration) Internationalisierung, Lokalisierung Input-Output-Daten Fehlerbehandlung
Typische Softwund typische Softwareanforderungen Fehlertoleranz ist eine Reihe von Systemeigenschaften, die die Systemzuverlässigkeit verbessern, indem sie Fehler erkennen, beheben und nachteilige Folgen für das System isolieren. Beim Entwerfen eines realen Systems zur Gewährleistung der Fehlertoleranz müssen alle möglichen Situationen, die zu einem Systemausfall führen können, antizipiert und Mechanismen zur Fehlerbehandlung entwickelt werden. Zuverlässigkeit ist die Fähigkeit eines Systems, verschiedenen Ausfällen und Ausfällen standzuhalten. Ausfall ist der Übergang des Systems infolge eines Fehlers in einen vollständig funktionsunfähigen Zustand. Ein Ausfall ist ein Fehler im Betrieb des Systems, der nicht zum Ausfall des Systems führt. Je weniger Ausfälle und Ausfälle über einen bestimmten Zeitraum, desto zuverlässiger gilt das System.
Typische Bestandteile der Softwareproduktarchitektur und typische Softwareanforderungen Umsetzungsmöglichkeiten der entwickelten Architektur. Möglichkeiten der Umsetzung der entwickelten Architektur. redundante Funktionalität. redundante Funktionalität. Entscheidung über den Kauf fertiger Softwarekomponenten. Entscheidung über den Kauf fertiger Softwarekomponenten. Strategie ändern. Strategie ändern.
Ist die allgemeine Organisation des Programms klar beschrieben; ob die Spezifikation einen Überblick über die Architektur und ihre Begründung enthält. Ist die allgemeine Organisation des Programms klar beschrieben; ob die Spezifikation einen Überblick über die Architektur und ihre Begründung enthält. Sind die Hauptkomponenten des Programms, ihre Verantwortungsbereiche und das Zusammenspiel mit anderen Komponenten angemessen definiert? Sind die Hauptkomponenten des Programms, ihre Verantwortungsbereiche und das Zusammenspiel mit anderen Komponenten angemessen definiert? Ob alle in der Anforderungsspezifikation spezifizierten Funktionen durch eine angemessene Anzahl von Systemkomponenten implementiert werden. Ob alle in der Anforderungsspezifikation spezifizierten Funktionen durch eine angemessene Anzahl von Systemkomponenten implementiert werden. Sind die wichtigsten Klassen beschrieben und begründet. Sind die wichtigsten Klassen beschrieben und begründet. Ob eine Beschreibung der Organisation der Datenbank gegeben wird. Ob eine Beschreibung der Organisation der Datenbank gegeben wird. Sind alle Geschäftsregeln definiert? Sind alle Geschäftsregeln definiert? Ist ihre Auswirkung auf das System beschrieben? Ist ihre Auswirkung auf das System beschrieben? Eine Checkliste mit Fragen, die einen Rückschluss auf die Qualität der Architektur zulassen:
Eine Checkliste mit Fragen, die einen Rückschluss auf die Qualität der Architektur zulassen: Ist die User-Interface-Design-Strategie beschrieben. Ob die Designstrategie für die Benutzeroberfläche beschrieben wird. Ist es fertig Benutzeroberfläche modular, so dass seine Änderungen den Rest des Systems nicht beeinflussen. Ob die Benutzeroberfläche modular aufgebaut ist, sodass Änderungen daran den Rest des Systems nicht beeinflussen. Ob eine Beschreibung der E/A-Strategie bereitgestellt wurde. Ob eine Beschreibung der E/A-Strategie bereitgestellt wurde. Ob eine Leistungsanalyse des Systems, das mit dieser Architektur implementiert wird, durchgeführt wurde. Ob eine Leistungsanalyse des Systems, das mit dieser Architektur implementiert wird, durchgeführt wurde. Wurde die Zuverlässigkeitsanalyse des entworfenen Systems durchgeführt? Wurde die Zuverlässigkeitsanalyse des entworfenen Systems durchgeführt? Wurde eine Analyse der Skalierbarkeit und Erweiterbarkeit des Systems durchgeführt? Wurde eine Analyse der Skalierbarkeit und Erweiterbarkeit des Systems durchgeführt?
Software-Refaktorisierung Code wird wiederholt; Methodenimplementierung ist zu groß; zu viele Verschachtelungen von Schleifen oder die Schleife selbst ist sehr groß; die Klasse hat eine schlechte Konnektivität (Eigenschaften und Methoden der Klasse sollten nur 1 Objekt beschreiben); eine Klassenschnittstelle bildet keine konsistente Abstraktion; Die Methode benötigt zu viele Parameter. Sie sollten versuchen, die Anzahl der Parameter auf ein vernünftiges Minimum zu beschränken; einzelne Klassenteile ändern sich unabhängig von anderen Klassenteilen; Refactoring umfasst die Anpassung von Software an neue Hardware und neue Betriebssysteme, neue Entwicklungstools, neue Anforderungen sowie Softwarearchitektur und -funktionalität. Dieser Wandel Interne Struktur Software, die ihr äußeres Verhalten nicht ändert und so konzipiert ist, dass Softwareänderungen möglich sind. Vernünftige Gründe für ein Refactoring:
Das Software-Refactoring beim Programmwechsel erfordert eine parallele Änderung mehrerer Klassen. Wenn eine solche Situation eintritt, ist es notwendig, die Klassen neu zu organisieren, um zukünftige Plätze zu minimieren mögliche Änderungen; mehrere Vererbungshierarchien parallel ändern müssen; Sie müssen mehrere Fallblöcke ändern. Es ist notwendig, das Programm so zu modifizieren, dass die Implementierung des Fallblocks erfolgt, und es so oft wie erforderlich im Programm aufzurufen; Verwandte Datenelemente, die zusammen verwendet werden, sind nicht in Klassen organisiert. Wenn Sie denselben Satz von Datenelementen wiederholt verwenden, ist es ratsam, diese Daten zu kombinieren und die darauf ausgeführten Operationen in einer separaten Klasse zu platzieren.
Eine Software-Refaktorisierungsmethode verwendet mehr Elemente einer anderen Klasse als ihre eigene. Das bedeutet, dass die Methode in eine andere Klasse verschoben und von der alten aufgerufen werden muss; der elementare Datentyp ist überladen. Um die Essenz der realen Welt zu beschreiben, ist es besser, eine Klasse zu verwenden, als einen vorhandenen Datentyp zu überladen; Die Klasse hat eine zu eingeschränkte Funktionalität. Es ist besser, diese Klasse loszuwerden, indem man ihre Funktionalität auf eine andere Klasse überträgt; "streunende" Daten werden entlang der Methodenkette weitergegeben. Daten, die an eine Methode übergeben werden, nur um an eine andere Methode übergeben zu werden, werden Streudaten genannt. Wenn solche Situationen auftreten, versuchen Sie, die Architektur von Klassen und Methoden zu ändern, um sie loszuwerden.
Das Umgestalten des Medienobjekts bringt nichts. Wenn die Rolle einer Klasse darin besteht, Methodenaufrufe an andere Klassen umzuleiten, ist es am besten, diesen Proxy zu eliminieren und Aufrufe direkt an andere Klassen zu senden. eine Klasse weiß zu viel über eine andere Klasse. In dieser Situation ist es notwendig, die Einkapselung strenger zu gestalten, um sicherzustellen, dass der Erbe nur minimale Kenntnis seines Elternteils hat; die Methode hat einen unglücklichen Namen; Datenmitglieder sind öffentlich. Dies verwischt die Grenze zwischen Schnittstelle und Implementierung, unterbricht unweigerlich die Kapselung und schränkt die Flexibilität des Programms ein; Kommentare posten Quellcode;
Eine Software-Refaktorisierungs-Unterklasse verwendet nur einen kleinen Bruchteil der Methoden ihrer Vorfahren. Diese Situation tritt auf, wenn neue Klasse wird nur erstellt, um einige Methoden von der Basisklasse zu erben und keine neue Entität zu beschreiben. Um dies zu vermeiden, muss die Basisklasse so transformiert werden, dass sie der neuen Klasse nur die Methoden zugänglich macht, die sie benötigt; der Code enthält globale Variablen. Nur Variablen, die tatsächlich vom gesamten Programm verwendet werden, sollten global sein. Alle anderen Variablen müssen entweder lokal sein oder Eigenschaften eines Objekts werden; Das Programm enthält Code, der möglicherweise eines Tages benötigt wird. Bei der Entwicklung eines Systems ist es ratsam, Stellen vorzusehen, an denen Quellcode in Zukunft hinzugefügt werden kann.
