Was genau sind eigentlich die Ergebnisse einer Entwurfsphase und Implementierungsphase? Einfach nur der fertige IT-Entwurf und das geschriebene Programm inkl. einer Dokumentation der Implemente? Oder gibt es noch weitere schriftliche Ergebnisse?

Beim Entwurf kommt bspw. iwas UML mäßiges raus (Use Case Diagramm) oder alternativ User Stories und bei der Implementierungsphase kommt Quelltext heraus :eek

Können User Stories nicht auch schon bereits vor der Entwurfsphase kommen?

EDIT: VOR der Entwurfsphase ... was soll das für ein Sinn haben, wen du nicht weißt was der Kunde haben will?

Bearbeitet 29. Januar 201015 j von Rookian

Können User Stories nicht auch schon bereits vor der Entwurfsphase kommen?

Natürlich. Unter Zuhilenahme einer geeigneten Glaskugel und mit der VHIT-Methode geht das. Haben wor vor dreißig Jahren gemacht: Erst programmiert, dann PAP gemalt und fest gestellt, dass das Programm eigentlich nicht laufen konnte.

Im Ernst: Du solltest dir erst Gedanken machen was du tun möchtest, dieses mittels Diagramme festigen (Design- oder Entwurfsphase) und dann Programmieren, Tabellen erstellen usw. (Implementierungsphase). Frei nach dem Motto:

Analyse,

Design,

Implementierung,

Test,

Abnahme,

Dokumentation.

Analyse,

Design,

Implementierung,

Test,

Abnahme,

Dokumentation.

ganz so richtig is das aber EIGENTLICH auch nicht Wenn du man erst ganz am Ende testet könnte es die ein oder andere böse Überraschung geben ... gleiches gilt wie ich finde auch für Abnahmen

Wenn du das so findest, ist das ja in Ordnung für dich persönlich. Die Testphase bitte nicht mit Entwickler- oder Schreibtischtests verwechseln. Hier sind Integrations-, Modul-, u.A. Tests gemeint. Lies dich mal in das Thema Vorgehensmodelle ein, da erfährst du den Unterschied zwischen genormten Prozessschritten und persönlichen Präferenzen.

Ok könnt ihr mir vielleicht genau sagen, was ich innerhalb der Analyse machen muss? gehen wir mal davon aus, dass ich nciht OOP machen will, sondern eher prozedualen Programmierung. Was muss da alles rein? Also in die Defintionsphase? Use-cases bzw. Anwendungsfälle? Ein OOA-Modell kann leider wegen prozedualer Programmierung nciht erstellen. Wäre ein einfach skizzierter Prototyp denkbar (Benutzeroberflächen etc.)?

ganz so richtig is das aber EIGENTLICH auch nicht Wenn du man erst ganz am Ende testet könnte es die ein oder andere böse Überraschung geben

Na dann werde ich Tester vor Implementierung. Anwesenheitspflicht besteht da ja nicht.

Unter Test ist hier etwas anderes zu verstehen, als ein Test einzelner zu etablierender Komponenten der während der Entwicklungszeit parallel durchgeführt wird.

Auch wenn alle Einzelheiten für sich bei mir funktionieren, muss es noch lange nicht in der Gesamtheit bei jedem funktionieren.

Ein Test nach Implementation beinhaltet neben den Funktionstest (also Test, ob alles geht) auch den Fehlertest (also Test ob und wie bestimmte Fehlerszenarien abgefangen werden). Sicher bin ich hier noch nicht vollständig (in denke gerade irgendwie an Black & WhiteBox etc.).

Du siehst, Test geht erst nach Implementation. Und Abnahme geht erst, wenn Test bestanden ist.

PS: Akku, wie machst du alter Mann immer alles vieles schneller als ich? Das deprimiert.

PS: Akku, wie machst du alter Mann immer alles vieles schneller als ich? Das deprimiert.

Ich bin näher dran!

Ok könnt ihr mir vielleicht genau sagen, was ich innerhalb der Analyse machen muss?

Was hast du?

Was willst du?

Wie soll es funktionieren?

Wie soll es aussehen?

Was kostet der Spaß?

gehen wir mal davon aus, dass ich nciht OOP machen will, sondern eher prozedualen Programmierung. Was muss da alles rein? Also in die Defintionsphase? Use-cases bzw. Anwendungsfälle?

Genau, für USE-Cases braucht man keine OO.

Ein OOA-Modell kann leider wegen prozedualer Programmierung nciht erstellen.

Must du nicht. Ein PAP(Programmablaufplan) und/oder ein wenig Pseudocode.

Wäre ein einfach skizzierter Prototyp denkbar (Benutzeroberflächen etc.)?

Genau sowas.

Wenn du das so findest, ist das ja in Ordnung für dich persönlich. Die Testphase bitte nicht mit Entwickler- oder Schreibtischtests verwechseln. Hier sind Integrations-, Modul-, u.A. Tests gemeint. Lies dich mal in das Thema Vorgehensmodelle ein, da erfährst du den Unterschied zwischen genormten Prozessschritten und persönlichen Präferenzen.

Integrationstest können (sollten sofern es geht) vom Entwickler gemacht werden und das am besten noch vollautomatisiert.

Was meinst du mit "genormten Prozessschritten"?

Bearbeitet 29. Januar 201015 j von Rookian

Integrationstest können (sollten sofern es geht) vom Entwickler gemacht werden.

Hat doch keiner bestritten

Was meinst du mit "genormten Prozessschritten"?

Lies doch bitte nochmal den Anfang des Satzes, in dem du diese beiden Wörter gefunden hast!

1. Was hast du?

2. Was willst du?

3. Wie soll es funktionieren?

4. Wie soll es aussehen?

5. Was kostet der Spaß?

1. Access Frontend mit SQL Server als Backend

2. In das Access Frontend Benutzeroberflächen integrieren und auf dem DB-Server neue DB-Tabellen und Views erstellen

3. Die Interaktion soll über die Benutzeroberflächen erfolgen.

4. Ganz einfache simple Benutzeroberflächen (meine Aufgabe ist auch nciht allzu komplex, also noch überschaubar)

5. Kosten müssen keine berücksichtigt werden

Riech für die Skizzierung des Prototypen eine Zeichnung per PowerPoint aus?

Bearbeitet 29. Januar 201015 j von Felix2000

Hat doch keiner bestritten

Lies doch bitte nochmal den Anfang des Satzes, in dem du diese beiden Wörter gefunden hast!

"Die Testphase bitte nicht mit Entwickler- oder Schreibtischtests verwechseln. Hier sind Integrations-, Modul-, u.A. Tests gemeint"

Was is denn nun eine Testphase und Entwicklertests?! Für mich gehören in eine Testphase Unit- und Integrationstests. Und die Phasen die du genannt hattest, sollten so wie ich es verstanden habe iterativ durchgeführt werden.

Ich hätte gedacht du könntest erklären was "genormte Prozessschritte" sind.

1. Access Frontend mit SQL Server als Backend

2. In das Access Frontend Benutzeroberflächen integrieren und auf dem DB-Server neue DB-Tabellen und Views erstellen

3. Die Interaktion soll über die Benutzeroberflächen erfolgen.

4. Ganz einfache simple Benutzeroberflächen (meine Aufgabe ist auch nciht allzu komplex, also noch überschaubar)

5. Kosten müssen keine berücksichtigt werden

Riech für die Skizzierung des Prototypen eine Zeichnung per PowerPoint aus?

Du bist zu tief in der Entwicklung. Siehe die Schritte aus Kundensicht. Du bist Berater. Kosten hast du sehr wohl. Überlege nochmal sehr genau und informiere dich hier, wie Projektanträge aussehen und was sie beinhalten müssen.

Ich hätte gedacht du könntest erklären was "genormte Prozessschritte" sind.

Ich helfe: Erkundige dich, was Vorgehensmodelle sind, dann erfährst du was genormte Prozessschritte sind.

Die Fragen 1.-4. sollte man aus Sicht und in der Sprache des Kunden bzw. potentiellen Anwenders beantworten.

Wenn das ganze im beruflichen Umfeld passiert, entstehen immer Kosten.

Das VT-Modell XT muss für IT-Projekte im Bund eingesetzt werden. Aber sonst gibt es doch keine Norm an die man sich halten muss oder versteh ich da was falsch?

Das VT-Modell XT muss für IT-Projekte im Bund eingesetzt werden. Aber sonst gibt es doch keine Norm an die man sich halten muss oder versteh ich da was falsch?

Nein must du nicht. Du kannst das Pferd auch von hinten aufzäumen. Ob dein PA das dann gut findet, ist eine andere Sache. Es gibt nun mal Dinge, die in einer festgelegten Reihenfolge abgearbeitet werden. Neben Scrum u.A. neuartigen Ansätzen, hat sich das iterative Wasserfallmodell (besonders bei den FI-Prüfungen, da leicht anzuwenden) erfahrungsgemäß etabliert.

Du bist zu tief in der Entwicklung. Siehe die Schritte aus Kundensicht. Du bist Berater. Kosten hast du sehr wohl. Überlege nochmal sehr genau und informiere dich hier, wie Projektanträge aussehen und was sie beinhalten müssen.

Ok das heißt ich muss den Pseudocode und PAP aus aus Sichtweise des Kunden erstellen oder versteh eich da jetzt was falsch?

Eine andere Frage: Wie bezeichnet man das eigentlich, wenn ich während meiner Implementierung etwas geschriebenes, programmiertes selbst austeste? Einfach nur Entwicklertest (Testmethode White Box Test)?

Bearbeitet 29. Januar 201015 j von Felix2000

Nein, PAP und Pseudocode sind Entwicklerzeugs.

Der Kunde sagt dir doch: Ich setze bisher ... ein. Dabei stört mich dass ... und es wäre schön wenn man ... könnte.

Wenn du Glück hast, kann der Kunde das so konkret formulieren, meist aber nicht, sondern er sagt dir nur was ihn stört, Zeit und Geld kostet.

Im "schlimmsten" Fall steckt der Kunde seit zig jahren in seinem System drin und denkt nicht mehr an Alternativen; dann mußt du als Berater die Schwachpunkte erkennen.

Eine andere Frage: Wie bezeichnet man das eigentlich, wenn ich während meiner Implementierung etwas geschriebenes, programmiertes selbst austeste? Einfach nur Entwicklertest (Testmethode White Box Test)?

Entwicklertest oder "nur" Test. Wobei man dabei wie schon geschrieben zw. Unittests (Komponententest) und Integrationstests (Verhalten sich Komponenten interaktiv korrekt) unterscheidet. Dabei gibt es das Problem das viele Leute meinen sie würden Unittests schreiben obwohl dies Integrationstests sind. In dem Buch "The Art Of Unit Testing" steht über das Testen eine ganze Menge

Wenn der Entwickler seinen Code selber testet ist es ein White Box Test, weil er seinen den Code kennt. Ansonsten is es ein Black Box Test bspw. wenn die QS, die den Quelltext nich kennt, dein Programm testet. Ob man von White Box oder Black Box Test spricht, wenn ein Entwickler einen fremden Quelltext testet weiß ich nicht, vll kann da ja jemand was zu sagen^^

Bearbeitet 29. Januar 201015 j von Rookian

Ich habe nochmal eine Frage zur Definitionsphase. Wenn mein Kunde hoffensichtlich zuviele Anforderungen von mir umgesetzt haben will, wie genau kann ich abwägen, dass das zeitlich nciht passt? Gibt es dafür eine Methode, Instrument etc.

Ich hatte zuerst auf User Stories gesetzt aber das darf ich ja angeblich hier nicht nehmen

Zum Beispiel indem du mit dem Kunden zusammen alle Anforderungen klassifiziert. Für kleinere Projekte sind da sicher 3 Prio-Klassen ausreichend. Umgesetzt werden dann die Anforderungen nach absteigender Prio, wobei man natürlich aus technische und sachliche Abhängigkeiten beachten sollte.

Zum Beispiel indem du mit dem Kunden zusammen alle Anforderungen klassifiziert. Für kleinere Projekte sind da sicher 3 Prio-Klassen ausreichend. Umgesetzt werden dann die Anforderungen nach absteigender Prio, wobei man natürlich aus technische und sachliche Abhängigkeiten beachten sollte.

Ok danke, für die Klassifizierung existiert aber im Rahmen der Softwareentwicklung kein etxra vorhandenes Modell oder eine standardisierte Verfahrensweise oder?

Ich kenne jetzt adhoc keine standardisierte Methode.