Programmentwicklung

[3of4]

Könntet ihr mir sagen wie ihr an eine Programmentwicklung herantretet. Brauche es für ein Referat, also wäre es schön wenn ihr wenn es geht wirklich von der Pike weg beginnt. Postet bitte alles ich betrachte nichts als unnötig

------------------
Mit dem Lesen diesen Postings haben sie erklärt, keine Beschwerden an dessen Schreiber zu stellen, auch wenn es im falschen Forum sein sollte. Bei Nichtbeachtung wird mein Abo gekündigt und sämtliche Webserver auf denen einer der 3 Buchstaben WCM vorkommt erhält gratis DoS

[DiabloII]

hab heute genau das gleiche referat zugeteilt bekommen. muss aber nur für den 68k machen.

welche sprache soll denn deins sein? oder allgemein?

[kikakater]

PaP (Profi an Profi)

1) Gliederung

. Anlegen des Pflichtenhefts
. Zweck des Programmes
. Portierbarkeit ja/nein
. Realisierung in wieviel Zeit (erste Grobabschätzung, diese Schätzung wird durch die nächste raffiniert, also verfeinert)
. Programmiersprache, Wiederverwendbarkeit, Kontaktzirkel (Cobolwelt, C, C++)
. Leistungsträger / Kostenträger / Realisator
d.h. ver macht die Mühle, wer bzw. was verbraucht die Geldmittel, wer bringt die Kiste zum Aufrechtstehen
. Sofistikationsebene: Soll es ein 08/15 Durchschnittsstangenprodukt sein oder soll Datenzugriff und Erreichbarkeit sowie Aussagekraft der Software wichtig sein

2) Datenmodell

. Normalisierung der aufgelisteten gewünschten Informationen
. Entscheidung, welche Daten als Tabelle, Ansicht (View) oder noch dynamischer gebildet werden sollen
. Realisierung in wieviel Zeit ? (2. ...)

3) Algoritmischer Ansatz auf logischer Ebene

. Eingabe, Verarbeitung, Zugriff, Ausgabe, Verwaltung, Pflege, Migration, Löschung, Filterung von Daten
. Steuer-Nachrichten der Prozeduren sowie zwischen Clients und Server(n), Verteilung von Daten und Prozeduren für Clients
. Erweiterbarkeit durch dynamische Abfragesprache innerhalb der Applikation (Abstraktionsschicht zur Datenspeicherungsebene hin)

4) Algoritmischer Ansatz auf physischer Ebene

. Durchführung von Auswertungen (Benchmarks)
. Auswahl der geeigneten Verfahren
. Fehlerquellenpinpointing (gnadenlos; vereinheitlichend)

5) Programmierung

. Wechselspiel Blatt Papier - RAD System - Compilierung - Testung - weiter
. Abhaken der Realisierungen, einschränkend auf wirkliche und teilweise funktionierende Abschnitte
. Nachhaken bei den Kollegen, falls Chef, sonst liefert der seine Arbeit ab an den Chef
. Chef muß Führungstalent haben

6) Alpha-Test

7) Rückkehr zu Punkt 5)

8) Beta-Test, Marketing setzt ein

9) Abnahme-Test(reihe)

10) Verkauf

Blöd wird es wenn das Datenmodell nicht richtig gewählt wurde, dann heißts nämlich, vergiß es !

Deswegen auch das Datenmodell ist entscheidend, nicht nur das sture perfekte Runterkodieren von einwandfreien Routinchen.

Es geht um 'relative' Metadaten, was ist das ?

Wenn man ein Datum satisfaktionsmäßig speichern will, braucht es eben mehr als zwei Ziffern für die Jahreszahl, egal ob Speicher teuer ist oder nicht !

Metadaten sind beschreibende Daten, relative Metadaten sind abbildende Datenwerte mit hohem Modulo, d.h. erst nach 1 Million Jahren ergibt sich das Problem, das Jahr 1 vom Jahr 1 Mio und 1 nicht unterscheiden zu können. Eindeutigkeit gehört zum Programmieren wie verbandelt dazu. Ist eine unlösbare Aufgabe, deswegen zumindest hohes Modulo wählen, damit Datenverarbeitung Sinn macht.

Bitte um weitere Beiträge von anderen Wissensanbietern, Kikakater

[3of4]

@diableII
Ich lerne c(und c++), und habe mir dieses Referat ausgewählt weil alle anderen schon vergeben waren(Geschichte, includedateien, ....) und weil ich was gegen die so sinnvollen Referate (wie der Gebrauch der Hilfedatei in c) habe. So glaube ich kann ich mich mit etwas auseinandersetzen dass ich auch durchaus verwenden kann.

@kikakater
Super Stoff, nur leider bin ich NOCH keiner mit dem man in PaP sprechen kann. Könntest du oder ein anderer es versuchen etwas mehr in Richtung fordummies zu machen?
Trotzdem Danke, mit einem Großteil des hier vorhandenen kann ich sicher viel anfangen.

[DiabloII]

hi prof. mailbember

mein referat geht weniger in die wirtschaftiche richtung sondern mehr in die technische entstehung des programmes. also beim 68k entwurf, editor, assemblieren, linken, simmulieren und irgendwo reinspeichern.

und so wie sich die anderen themen anhören wird von dir in etwa das gleiche verlangt. sicher, über den stoff von kikakater könntest stundenlang reden aber einfacher ists halt wennst nur über den programmier und kompilier(oder wies halt bei den c´s ist) vorgang redest.

[Dieser Beitrag wurde von DiabloII am 17. Februar 2001 editiert.]

[kikakater]

Nicht böse sein, Programmieren für Dummies führt auch .. zu nicht besonders berauschenden Programmen. Es wurde viel zu lange irgendwie programmiert, Wald und Wiesen Programme.

Es fängt mit dem Nachdenken an was für ein Problem sich einem stellt, das man programmtechnisch einfacher machen will.

Wenn man um das Programm weiß, z.B. 'ich will eine KfZ-Verwaltung machen', Fuhrpark etc., dann kann man dazu übergehen, sich vernünftige Datenstrukturen zu überlegen, die die einzelnen Datensätze representieren können.

Hat man die auch, es handelt sich wirklich um einzelne Datenfelder entweder mit struct { oder PIC S9(5)V99. oder dergleichen oder eben mit class beschriebene Objektzusammensetzungen (an Membern).

Sind die einzelnen Datenstrukturen für unsere Fahrzeuge und Fahrer und Kreditgeber und Lieferanten und Kunden und Mechaniker ausdefiniert, so versucht man die Kopiereinrichtungen und Lese- sowie Schreibvorgänge wie Visualisierungen und Hardkopierungen (Ausdrucke, Listen) als programmtechnisches Verknüpfungswerk zu fassen. Hat man das Menübäumchen auch erledigt, so bleibt es einem überlassen, die einzelnen Routinen, so auszuformen, daß möglichst mit den gleichen Zugriffsroutinen auf die Daten zugegriffen wird, die Daten aufbereitet werden und irgendetwas Sinnvolles mit diesen Daten gemacht wird, wie beispielsweise speichern oder drucken oder aufsummieren.

Sollte das noch immer zu theoretisch sein oder irgendwie anders, dann sag ich nur, Du mußt offensichtlich ein konkretes Beispiel komplett durchkauen.

Am besten hinsetzen und ein Programm schreiben und immer wieder - parallel dazu - beschreiben, welche Überlegungen eine Rolle spielen und was man bis zum Zeitpunkt des Knopfaufgehens übersehen hat. Das hilft Dir im konkreten Fall wahrscheinlich am besten weiter, lasse nun andere ran, bis auf weiteres ...

[kikakater]

Falls es Dir um das reine Kodieren geht, also die Programmierung, so ist das nur ein Teil der ganzen Programmentwicklung.

Dazu brauchst Du logisches Wissen über EDV-Grundsätze, z.B. wo fängt man zu zählen in der EDV, bei 1 oder doch vielleicht bei der 0 ? Unabhängig von der Zählweise jetzt: Soll man 0 als Signalisierung verwenden, oder ist es doch der sogenannte NULL (sprich NALL) Wert ?

Du mußt wissen, daß das ASCII-Zeichen dezimal 65 das große 'A' ist, und das man 32 zu einem 'Großbuchstaben' ASCII-Zeichen hinzuaddieren muß um einen 'Kleinbuchstaben' zu bekommen als char-Wert.

Du mußt mit geschwungenen Klammern umgehen können, mit #defines, also Textkonstanten, die durch ihren definierten equvivalenten Inhalt ersetzt werden zur Kompilierzeit. Und noch und nöcher.

Wie schreibe ich ein C-Programm:

Kenntnisse über eine Funktion:

eine Funktion hat einen Rückgabewert, void ist ein typenloser Rückgabewert, es wird auch nichts zurückgegeben, falls void funktionsname( ... )

Die Grunddatentypen sind int (16bit, zumeist) vorzeichenbehaftet (das Vorzeichenbit ist das Höchstwertigste), long(32bit, zumeist), char/unsigned char, unsigned int bzw. long, es gibt float, double, long double, Bitfelder, Strukturen, Unions (Redefinitionen des selben Speicherbereichs), Zeiger auf alle diese Datentypen sowie Zeiger auf Funktionen. Zeiger definiert man mittels datentyp *zeigername, auf die Daten greift man mit *zeigername wieder zu, es gibt Arrays von Datentypen wie auch Zeigerarrays, dessen Zeigerelemente wieder auf Zeiger weisen können.

char **zeigeraufzeiger zum Beispiel ...

es gibt Parameterlisten, die nach ANSI innerhalb der Klammern typisiert werden und auch einen (Funktions-)prototyp (möglichst) in einer include-Datei besitzen sollen.

es gibt variable Parameterlisten, wie zum Beispiel bei der Funktion printf und Anverwandten deren Prototyp so aussieht:

int printf (const char *format, ...);

Die Funktion, die den Einsprungspunkt abgibt in C, ist main ( ), die eine Argumentliste von der Kommandozeile des Betriebssystems aufnehmen kann.

Es gibt globale Variablen, lokale, statische, wie auch Referenzen (nur) in C++ mit &referenz gekennzeichnet).

Eine Funktion sollte einen aussagekräftigen Namen haben, z.B. PrintVendorNames() oder DruckeZulassungdaten().

Der Namensgebung ist überhaupt entscheidende Überlegung zu widmen, da so viele Fehler gemacht und vermieden werden.

Ein Genius musst Du schon alleine werden, das dauert 10 Jahre bis sich da etwas abzeichnet, und in dieser Zeit solltest Du auch intensiv über das Programmieren nachdenken, das Ausführen der Tätigkeit selber ist eher nur hinderlich, sobald Du Deine Reifung bemerkst, kannst Du loslegen, und himmelschreiende Fehler begehen, deswegen programmieren reicht nicht, Du musst vom Geist der Desillusionierung erfahren haben, bevor Du es richtig machen kannst, mit der gleichen Intention, die Du jetzt hast, allerdings ohne die blutigen Anfängerfehler wieder und wieder zu machen.

Das war nur ein kleiner Nachtrag, kikakater

[Andre@s]

Ihr habt da Eines vergessen glaube ich: Es kommt darauf an, in welcher Branche man arbeitet. Ich bin z.B. bis jetzt im kaufm. Bereich, in der indiv. Programmierung für Großhandel und Krankenhausbereich tätig gewesen (bins noch immer).

Da zählt am Anfang nicht unbedingt dein Einfall, was du für ein Programm schreiben willst, sondern die Kunden treten an dich heran (im besten Fall, sonst mußt halt keilen gehen), welches Programm sie brauchen.

Also zuerst Kundenwunsch - Analysieren - Angebot für Pflichtenheft und Organisation - Pflichtenheft - Datenbankdesign - Programmierung - Testen - Programmierung - Lieferung und Installation - Schulung - Nachschulung - Nachschulung - (Kunden sind zum Teil sehr dumm) - Nachschulung (es gibt die ganz Dummen auch) usw.

Irgendwo dazwischen muß man noch Fehler korrigieren (kein Programm läuft auf Anhieb fehlerfrei - Meine Meinung hat sich bisher immer bestätigt - und wenn es nur der Kunde anders will).

Also da gibts in der Programmentstehung schon Unterschiede, und vereinheitlichen kann man das eigentlich nicht; meine Meinung.

Auch bis du einmal wirklich gut organisieren kannst, dauert es einige Jahre. Da zählt sehr viel die Erfahrung sowohl in der Programmierung wie auch Datendesign und Durchführbarkeit des Ganzen durch das Programm UND durch den Kunden!

[kikakater]

Es ist hier nicht ums Programmieren am Kunden gegangen, sondern ums Herangehen ans Programm entwickeln (lernen) OHNE einen Kunden zu haben, es geht ums Lernen.

Ich habe und lerne die Kunden immer als einen Haufen unterschiedlichster Leute kennen, die aber Leistung sehen wollen und z.T. nicht so sehr Bescheid wissen.

Das beste sind immer diejenigen, die immer mehr und mehr wollen, soweit ich weiß kann man sein Gehirn nicht teilen oder durch niederschütten mit Energiehältigem wesentlich leistungsfähiger bekommen. Es ist ein klares Mitteilen dem Kunden gegenüber gefordert, damit der weiß, daß er von mir/uns DAS und DAS nur bei entsprechender Bezahlung und bei Verständnis mit der Termingebarung bekommen kann.

Die Kunden müssen einsehen, daß vieles zwar zu realisieren ist, aber es geht unmöglich, daß man den 2000er Jahrgang und das Jahr 2001 in einem machen kann, sowohl von der Quantität wie auch von der qualitativen Entwicklung her.

Dies ist schlicht unmöglich, selbst wenn ich 20 neue einstelle, ist es in Teilbereichen nicht so einfach, weil es aussenliegende Entscheidungsgrundlagen und Parameter gibt.

Seine Harley Davidson versteht der Kunde, seine Businessprobleme versteht er auch noch, aber die Probleme eines Softwareentwicklers wohl schon weniger, vor allen Dingen weil es eine 'Wer zahlt schafft an' Situation ist.

Oft zahlen sie ja nicht, oder lassen sich bitten, gleiches mit DDS Bändern, die haben einen nicht unerheblichen Wert für ein Unternehmen, manche schicken die Bänder nicht zurück, muss'te ihnen im Nachhinein verrechnen. Ja, ja der Igenieur hat's schwer ...

Wenn man einen Kunden hat, der etwas will, so muß er es in einem Fax bestätigen, was er will und ob er den Preis dafür bezahlt. Angebote sind vom Kunden schriftlich bestätigend abzuzeichnen, damit klar ist, was ausgemacht wurde.

Sollte ein Kunde dies nicht tun, ist Fingerspitzengefühl gefragt, und letzten Endes sollte kategorisch auf Bezahlung von Leistung hingewiesen werden, wenn einer tausend Dinge nachträglich hineinrequiriert in ein preisliches Vertragsgefüge.

Protokollfunktion ist da nicht fehl am Platz, bitte immer freundlich bleiben, der Kunde ist schließlich nicht Feind sondern unwissend und zum Teil anmaßend.

tales from the practice ..., Kikakater

--------------------------

Tut leid, wenn ich nichts einfacheres berichten kann, es handelt sich um das Leben und nicht um ein sauber aufbereitetes Buch, für das man Zeit hatte und das in einem reifen konnte.