tasktlogger-devel Mailing List for Task Tracker and Logger (Page 5)
Brought to you by:
teiniker
Menu
▾
▴
tasktlogger-devel — TaskLogger Developer List
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(108) |
Nov
(10) |
Dec
(15) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ritzinger J. <Jak...@fh...> - 2006-10-09 19:56:58
|
Hallo! Ich schau mich mal nach einem passenden Dokument um und leite es dann an = die Integrationsgruppe weiter. Bin f=FCr Vorschl=E4ge/Anregeungen/Bescherden nat=FCrlich immer direkt = ansprechbar (bitte nicht =FCber die Mailing List). LG, Jakob |
|
From: Pratter T. <Tho...@fh...> - 2006-10-09 13:40:57
|
-----Original Message----- From: Pratter Thomas Sent: Mon 09.10.2006 15:36 To: tas...@li... Subject: nochmal architektur =20 hallo, wir k=F6nnten auch erst einen gemeinsamen Kontext schaffen, also die = Kontext relevanten Aufgaben auf die Gruppen aufteilen:=20 DB Schnittstelle Schnittstelle UI -> Businesslogik (inkl Sessionmanagement) Frontenddesign und Sitemap und dann zu den user stories pro Gruppe zur=FCckkehren. |
|
From: Pratter T. <Tho...@fh...> - 2006-10-09 13:31:22
|
hallo, wir k=F6nnten auch erst einen gemeinsamen Kontext schaffen, also die = Kontext relevanten Aufgaben auf die Gruppen aufteilen:=20 DB Schnittstelle Schnittstelle UI -> Businesslogik (inkl Sessionmanagement) Frontenddesign und Sitemap und dann zu den user stories pro Gruppe zur=FCckkehren. |
|
From: Szirch M. <Mic...@fh...> - 2006-10-09 11:36:28
|
Hallo, Ich denke, dass wir verst=E4rkt mit Interfaces arbeiten sollten. Sowohl f=FCr die Business-Objekte als auch f=FCr die Datenbankobjekte, damit wir Datenbanken ohne Probleme austauschen k=F6nnen und ebenso wird man mit Interfaces gezwungen sich an die Struktur zu halten = und es wird dann auch leichter, wenn die Tasks auf Gruppen aufgeteilt sind.=20 Auf eine Notation m=FCssen wir uns aber einigen und die = Integrationsgruppe sollte diese Grundvereinbarungen in einem File ablegen. Wie auch schon von Martina angek=FCndigt, k=F6nnte unsere Gruppe die = Interfaces f=FCr die Datenbankanbindung bzw. Persistenzschicht =FCbernehmen (inkl. = der ExportMethoden)=20 dann w=E4re es noch gut, wenn sich eine Gruppe Gedanken =FCber ein = Interface f=FCr die BO=92s machen w=FCrde. Dies ist als Diskussionsgrundlage f=FCr heute Abend gedacht. Bis heute am Abend Lg Michael=20 |
|
From: Ritzinger J. <Jak...@fh...> - 2006-10-09 11:06:30
|
testtext testtext |
|
From: Roland W. <wal...@gm...> - 2006-10-09 10:42:52
|
Hallo, > - Java 1.5 > - Servlets, JSP > - JDBC, SQL wurde im Rahmen des Studiums behandelt. > - Ant > - JUnit > - Subversion wurden soweit ich mich nicht vertue im Rahmen des Sutidums noch nicht behandelt. Für UML gab es keine expliziete Vorlesung die benötigten UML Konstukte im Umfang des Projektes sollten jedoch die meisten kennen und verwenden können. (hier stellt sich eher die Frage nach einem gemeinsamen Modellierungstool für UML und welche Teile in UML modelliert werden.). Design Pattens werden die Programmierer unter uns bestimmt kennen, eine Vorlesung dazu gibt es im Rahmen des Studium jedoch erst im 7. Semester. Ich kann für nächste Woche auch die deutsche Fassung des Buchees von Gamma und co mitnehmen. mfg Roland WALTER -------- Original-Nachricht -------- Datum: Mon, 9 Oct 2006 12:23:47 +0200 Von: "Teiniker Egon" <Ego...@fh...> An: "tasktlogger-devel" <tas...@li...> Betreff: [Tasktlogger-devel] Technologien > Hallo miteinander, > > ich hätte noch eine Frage bzgl. der verwendeten Technologien - verwenden > wir eine Technologie die Sie im Rahmen der FH noch nicht kennengelernt > haben? > > Zur Erinnerung: > - Java 1.5 > - Servlets, JSP > - JDBC, SQL > > - Ant > - JUnit > - Subversion > Wenn es Probleme geben sollte, melden Sie sich bitte bei mir, damit ich > einsprechende Beispiele für Sie bereitstellen kann. > > Wie schaut es mit UML aus? > > Wie schaut es mit Design Patterns aus? > > mfg > Egon Teiniker -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer |
|
From: Manuel E. <ma...@pe...> - 2006-10-09 10:30:08
|
"Teiniker Egon" <Ego...@fh...> schrieb: > Hallo miteinander, >=20 > ich h=E4tte noch eine Frage bzgl. der verwendeten Technologien - verwende= n wir > eine Technologie die Sie im Rahmen der FH noch nicht kennengelernt haben? >=20 > Zur Erinnerung: > - Java 1.5 > - Servlets, JSP > - JDBC, SQL Diese Technologien haben wir schon kennen gelernt > - Ant > - JUnit > - Subversion Diese Technologien wurden an der FH noch nicht unterreichtet. lg Manuel __________________________ send via peak.at webmailer |
|
From: Teiniker E. <Ego...@fh...> - 2006-10-09 10:19:06
|
Hallo miteinander, ich h=E4tte noch eine Frage bzgl. der verwendeten Technologien - = verwenden wir eine Technologie die Sie im Rahmen der FH noch nicht = kennengelernt haben? Zur Erinnerung: - Java 1.5 - Servlets, JSP - JDBC, SQL - Ant - JUnit - Subversion Wenn es Probleme geben sollte, melden Sie sich bitte bei mir, damit ich = einsprechende Beispiele f=FCr Sie bereitstellen kann. Wie schaut es mit UML aus? Wie schaut es mit Design Patterns aus? =20 mfg Egon Teiniker |
|
From: Teiniker E. <Ego...@fh...> - 2006-10-09 10:09:34
|
Hallo miteinander,
ich habe die Diskussion mit Interesse verfolgt und m=F6chte dazu =
folgendes sagen:
o) Ich bin immer begeistert, wenn Vorschl=E4ge von Studenten kommen und =
wir dar=FCber diskutieren k=F6nnen - ich denke das ist ja der Sinn der =
Veranstaltung. Also sagen Sie bitte Ihre Meinungen!
o) F=FCr die Planung des Projekts ist es in jedem Fall notwendig, die =
User-Stories zu analysieren und in Tasks aufzuteilen. Wenn Sie das bis =
zum Ende der Woche machen, k=F6nnten wir am Sa noch diverse =
Priorit=E4ten setzen und Probleme beseitigen.=20
o) F=FCr die Organisation der Teams (konkret f=FCr die Zuordnung Taks zu =
Teams) gibt es zumindest zwei Ans=E4tze:
(1) Technologie orientierte Teams (Web Team, DB Team, BL Team, etc. =
wie es Herr Walter vorschl=E4gt)
(2) User-Story orientierte Teams (mein Vorschlag siehe =
Iteration1-Organisation)
=20
Da Software Engineering keine exakte Wissenschaft ;-), und auch stark =
von der jeweiligen Anwendungsdom=E4ne abh=E4ngig ist, gibt es =
prinzipiell keinen absolut richtigen Weg!
Ich m=F6chte aber kurz argumentieren, warum ich Ansatz (2) gew=E4hlt =
habe:
o) Das Wichtigste an einem Projekt ist, dass der Kunde zufrieden ist.=20
Daher haben die Kunden-Anforderungen (User-Stories) absolute =
Priorit=E4t. =20
Die Wahl der Architektur richtet sich nach den Anforderungen des =
Kunden (mit welcher Architektur kann ich die Anforderungen gut =
umsetzen).
o) Es ist selten, dass sich die Architektur innerhalb eines Projektes =
=E4ndert (die Erfahrung zeigt, dass Architekturen innerhalb einer =
Dom=E4ne meist einige Projekte =FCberdauern).=20
F=FCr gr=F6=DFere Projekte gibt es oft ein eigenes Architektur-Team, =
das sich mit der Implementierung und Weiterentwicklung der Architektur =
besch=E4ftigt.=20
Zu einer Architektur geh=F6ren auch entsprechende Vorgehensweisen =
(Regeln f=FCr die Applikationsprogrammierer) zB: wie wird auf die DB =
zugegriffen, wie werden User-Requests verarbeitet, etc. Man kann daher =
davon ausgehen, dass die Applikationsprogrammierer (nach einer =
Lernphase) mit der Architektur vertraut sind, und wissen wie sie zB: ein =
DAO implementieren (oder aus einem Modell generierten) k=F6nnen.=20
o) Es mu=DF auch zwischen Design und Implementierung unterschieden =
werden.=20
Das grobe Design betrifft immer alle Teams, und mu=DF gemeinsam =
erarbeitet werden (das sollte das Integrationsteam koordinieren).=20
Kleine =C4nderungen (zB: ein Attribut in der Category Klasse =
hinzuf=FCgen) und Refactorings sind den Entwicklern =FCberlassen, die ja =
alle auf einem gemeinsamen Source-Stand arbeiten (dank Subversion).
Daraus folgt:
=3D> Architektur- und Grob-Design erfolgen eher am Beginn eines =
Projets und =E4ndern sich meist nur geringf=FCgig.=20
Diese Kommunikation kann etwas "teurer" sein, d.h. die Teams reden =
untereinander (es sind dann meist auch alle Teams betroffen).
In diesem Zusammenhang kommt auch die Rolle eines =
Software-Architekten ins Spiel (das w=E4r doch was f=FCr's =
Integrationsteam).
=3D> Die User-Stories kommen vom Kunden und =E4ndern sich oft nach =
jeder Iteration.=20
Daher ist es sinnvoll, die Kommunikation f=FCr eine User-Story =
"billig" zu machen, d.h. es reden die Entwickler eines Teams =
miteinander.=20
=3D> Auch Bugfixes, die sich aus Kundensicht einer User-Story =
zuordnen lassen, sollten innerhalb eines Teams gefixt werden k=F6nnen =
(statt einen Verantwortlichen in jedem Layer suchen zu m=FCssen).
o) Eine Agile Vorgehensweise bedeutet auch, dass es eine sehr enge =
Kopplung der Teams =FCber den gemeinsamen Source Code gibt. Jeder =
Entwickler checkt den gesamten Code aus und implementiert seinen Task =
dazu. Es ist daher erw=FCnscht =FCber die Team-Grenzen hinaus Source =
Code zu lesen, um Redundanzen zu finden und zu beseitigen (Entwickler =
m=FCssen miteinander reden!!).
o) Die User-Story orientierte Organisation der Teams erlaubt ja auch die =
Spezialisierung von Entwicklern (Web, DB, BL, etc.), wobei Entwickler =
die sich in verschiedenen Layers auskennen zu bevorzugen sind =3D> =
bessere Skalierbarkeit des Teams.
Ich freue mich auf Ihre Anmerkungen...
Liebe Gr=FC=DFe
Egon Teiniker
-----Original Message-----
From: tas...@li... on behalf of =
Martin Kuhn
Sent: Sun 10/8/2006 9:43 PM
To: tas...@li...
Subject: Re: [Tasktlogger-devel]Input Realisierungsans=E4tze, =
Architektur
=20
Hi,
=20
die Gruppen w=FCrde ich auch ganz anders aufteilen aber irgendwie war =
der Hr.
Teiniker von meinem Vorschlag nicht wirklich begeistert.=20
Ich bin aber pers=F6nlich auch auf jeden Fall der Meinung dass eine =
Aufteilung
wie sie Roland beschrieben hat viel zielf=FChrender w=E4re.
=20
LG
=20
Martin
=20
_____ =20
Von: tas...@li...
[mailto:tas...@li...] Im Auftrag von
Roland Walter
Gesendet: Sonntag, 08. Oktober 2006 21:37
An: tas...@li...
Betreff: [Tasktlogger-devel] Input Realisierungsans=E4tze, Architektur
=20
Hallo,
=20
bin ganz beim Martin. Auch wenn der Umfang des Projektes "klein" ist =
m=FCssen
einige Definitionen getroffen werden, welche bei einem gr=F6=DFeren =
Projekt
nicht viel
anders aussehen.
=20
Nur ein paar Anregungen:
* In welche Schichten wird die Anwendung aufgeteilt=20
* (Vorschlag f=FCr Projektgr=F6=DFe BusinessLogic mit Persistenzmethoden =
und
Oberfl=E4che)
* Namenskonventionen (Anwendung, Datenbank, Programmfiles,
Ordnerstruktur)
* Oberfl=E4chentemplate
* Wo werden Aktionsbuttos positioniert
* Wie sieht die Optik der Detail und =DCbersichtsseite aus
* Wo werden welche CSS Klassen eingesetzt
* Benennung =DCbersichtsseite, Detailseite und Auswertungsseiten,
Ordnerstruktur
usw.
=20
=20
Da es unser Ziel als Gruppe ist, die Aufgabenstellung zu l=F6sen, wei=DF =
ich
nicht in wie weit wir dabei selbst Entscheidungen treffen k=F6nnen.
Mein Vorschlag w=E4re eine ganz andere Projektstruktur, welche aus =
meiner
Erfahrung sehr gut funktioniert.
Somit w=FCrde ich die Gruppen wie folgt ausrichten:
* Gruppe A: Integration
* Gruppe B: Projektvorgaben (Namenskonventionen.),
Oberfl=E4chentemplates, DB Modell (Aufbau und Betreuung bei =
=C4nderungen)
* Gruppe C: Businesslogic + Persistenz f=FCr Objekte sicherstellen.
* Gruppe D: Oberfl=E4chenentwicklung und Visualisierung der Auswertungen
(Auswertungslogik klarerweise in Businesslogic)
=20
=20
Dadurch h=E4tten alle Teams klare Aufgaben und jedes Team hat seinen =
Bereich
wo es sich bewegt, anstatt dass jedes Team alle Schichten abbilden
muss. Weiters w=FCrden die Schnittstellen unter den Teams wesentlich =
kleiner
werden und die Koordination vereinfacht. Jedes Team sollte in jedem Fall
einen Verantwortlichen f=FCr die Abkl=E4rung der Schnittstellen zwischen =
den
Teams ernennen.
=20
So, ich hoff jetzt gibt's mal ne Diskussion =FCber das Thema ;o)
=20
LG
Roland
|
|
From: Roland W. <wal...@gm...> - 2006-10-09 09:17:35
|
-------- Original-Nachricht -------- Datum: Mon, 9 Oct 2006 09:26:18 +0200 Von: bir...@kn... An: st...@ei... Betreff: Software Engineering 3 - Heute 20:00 Uhr dringendes Meeting für alle Gruppen Hallo zusammen! Da es bereits Diskussionen betreffend die Aufgabenverteilung und die dafür benötigten - im Voraus zu treffenden - Definitionen gegeben hat, bitte ich alle, für die es zeitlich irgendwie möglich ist, heute (Montag, 09.10.2006) um 20:00 im Teamspeak zu sein. Ich habe bereits heute morgen eine Diskussion zu diesem Thema mit Martina geführt und wir haben folgenden Vorschlag zur Behebung beinahe aller bisher aufgetenen Probleme: Die Aufgaben werden nicht nach User-Story-Kapitel auf die Teams verteilt, sondern jedes Team hat ein Aufgabengebiet. Unser Vorschlag dazu sieht wie folgt aus: Team Martina: Datenbanken Team Birgit: Business logic Team Thomas/Martin K.: GUI Jedes Team behält mal das User-Story-Kapitel, das es bisher gewählt hat und zerteilt es in die drei Gebiete Datenbanken, Business logic und GUI (Tasks) und meldet diese Information an das Integrationsteam. Das Integrationsteam fasst die Tasks nach Aufgabengebiet zusammen und leitet die Aufgaben an die Teamsprecher der jeweiligen Teams weiter. Folgende Dinge wären somit heute abend zu besprechen: a) ist diese Vorgangsweise für alle ok? b) wir sollten über Namenskonventionen sprechen c) das Team "Integration" würde somit zum Team "Projektmanagement", da die Integration durch die Teilung ziemlich flach fällt @Team Thomas / Martin und Team Integration: Bitte stellt sicher, dass zumindest eine Person von euren Teams heute abend Zeit hat, mein Team sowie das Team von Martina sind auf jeden Fall vertreten. Ich denke, mit disem Ansatz können wir das Chaos weitgehend verhindern. LG Birgit Birgit Mitterer Software Engineering ----------------------------------------------------------- KNAPP Logistik Automation GmbH Software Division Guenter-Knapp-Strasse 5-7 8075 Hart bei Graz, Austria ----------------------------------------------------------- Phone: +43 316 495-1377 Fax: +43 316 495-99-1377 bir...@kn... www.knapp.com -- GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist! NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl |
|
From: Pratter T. <Tho...@fh...> - 2006-10-09 08:30:52
|
hallo, anscheinend haben nicht alle meine mail von samstag bekommen, daher = schicke ichs ganz einfach nochmal. hab da mal was gebastelt und ins svn eingecheckt unter = /dev/architecture. das ist nur ein vorschlag zum diskutieren, erweitern, = als schlechtes Beispiel ;-) weiters gibts unter /dev/db schon sql scripts zum erweitern (f=FCr mysql = und hsqldb) lg, thomas |
|
From: Martin V. <mar...@fh...> - 2006-10-09 07:17:13
|
Hallo allerseits, ich bin auch der Meinung, dass es sich mitunter als ziemlich schwierig herausstellen könnte, die Implementierung nach User-Stories aufzuteilen. Sinnvoller wäre da auch eine Aufteilung nach den einzelnen Implementierungsschichten (zB. Presentation, Business, DB). Da Herr Teiniker - lt. Martin - von dem Vorschlag nicht sehr begeistert war, würde ich folgendes Vorschlagen (zumindest was den DB-Layer angeht): - DB-Modell wie Christian schon vorgeschlagen hat - DB-Layer: Implementierung lt. DAO Design Pattern (Data Access Objects): so ist Switch auf eine andere DB sehr leicht zu implementieren. Wenn wir das so machen, dann kann ich ein grundlegendes Klassendiagramm bzw. die Basisklassen inkl. Implementierungs-Bsp. zur Verfügung stellen (Martina und ich haben das bei unseren Projekt IADS im vorigen Semester so gemacht). Da die User-Stories eh ziemlich ähnlich sind, ist dann eine Implementierung aller anderen Zugriffe nicht weiter schwierig. lg Martin |
|
From: Eisendle C. F. <Chr...@fh...> - 2006-10-09 06:20:15
|
Guten Morgen, eine kleine Anmerkung meinerseits: Auch die Userstories selbst =E4hneln = sich sehr, vor allem in der Programmlogik (Import/Export Funktionen in = XML und CSV) - also sollten wir uns da auch unter den Teams absprechen = (Auch wenn ich pers=F6nlich eine andere Teameinteilung wie sie z.B. = Roland und Martin vorschlagen besser finden) Zum Thema SQL-Scripts: Da die Datenbankstruktur eines der ersten Sachen = ist, die auf uns zukommen w=FCrde ich f=FCr diesen Schritt vorschlagen, = dass jedes Team f=FCr seine User Stories die SQL-Scripte entwirft und = dann ins Subversion Repository stellt - das Integrationsteam k=F6nnte = dann z.B. die Constraints zwischen den einzelnen Tabellen (also User = Stories) herstellen Des weiteren stimme ich Martina zu und finde, dass sich jedes Team mal = Gedanken zu den einzelnen Schnittstellen machen sollte und dann = entscheiden wir uns f=FCr einen Entwurf. lg Christian |
|
From: Rossmann M. <Mar...@fh...> - 2006-10-09 05:02:58
|
Guten Morgen! Ich finde die Idee von Roland super und diese wollte ich auch in dieser = Form (oder ziemlich =E4hnlich) vorstellen. Wir sollten das Projekt so gestalten, dass jedes Team (z.B. Team f=FCr = Datenbank-Layer) klar eine Schnittstelle - in Absprache mit den anderen = Gruppensprecher - definiert und diese nach au=DFen kommuniziert. Egal = wie die Implementierung innerhalb des Teams aussieht, sollten sich die = User-Stories dann leicht integrieren lassen. Vielleicht sollten wir in dieser und n=E4chster Woche folgendes = versuchen: - User Stories wie gehabt in den Gruppen zu zerpfl=FCcken und die = einzelnen Tasks allen anderen weitergeben - zus=E4tzlich grunds=E4tzliche Konventionen bestimmen und = ver=F6ffentlichen - vielleicht auch die Schnittstelle f=FCr die =FCber- und = untergeordneten Layers (in Absprache mit den anderen Teams) definieren = und ver=F6ffentlichen Heute am Abend werde ich aus unserem letzten Projekt (IADS) eine = =DCbersicht der Layers ins Netz stellen und mit dieser Implementierung = des DB-Zugriffs, k=F6nnen wir jede x-beliebige Datenbank ohne = zus=E4tzlichen Programmieraufwand verwenden. Bitte um Einw=E4nde/konstruktive Kritik/R=FCckmeldungen! Danke! lg Martina |
|
From: Michael S. \(FH\) <Mic...@fh...> - 2006-10-08 20:57:57
|
Hallo,
=20
Ich denke auch dass wir hier einheitliche Vorgaben brauchen.
=20
1. Wir sollten auf jeden Fall ein 3-Schicht Modell verwenden
Pr=E4sentationsLayer - BusinessLayer - PersistenzLayer
weil wir=20
a) Datenbankunabh=E4ngig bleiben m=FCssen
b) F=FCr alle Dialoge unterschiedliche Exportfunktionen brauchen.
2. Wir sollten uns wie meine VorPoster schon angemerkt haben auf eine
Notation einigen.
Mein Vorschlag w=E4re, das wir die Ungarische Notation verwenden da =
sie am
bekanntesten ist
3. Einigen sollten wir uns auch wie wir Methoden, Attibute ect benennen.
(Deutsch oder Englisch)
Mein Vorschlag zu dem Thema w=E4re wir verwenden Englisch.
4. Datenbankdesign: Ich schlage ein ER-Diagramm vor. (Wie schauts da mit
Visio aus - hat das jeder oder sollten wir ein OpenSource Tool =
verwenden?)
5. Einheitliches Layout - Wir sollten eine Vorlage produzieren und diese =
ins
Repository stellen.
6. Die Integrationsgruppe sollte eine Gruppe mit der Aufgabe des Layouts
(k=F6nnte sie theoretisch auch selber machen) beauftragen.
=20
- je genauer wir uns auf eine gemeinsame Vorgehensweise machen, desto =
besser
wird diese Art der Gruppenteilung funktionieren.
lg an alle =20
_____ =20
Von: tas...@li...
[mailto:tas...@li...] Im Auftrag von
Martin Kuhn
Gesendet: Sonntag, 08. Oktober 2006 21:43
An: tas...@li...
Betreff: Re: [Tasktlogger-devel]Input Realisierungsans=E4tze, =
Architektur
Hi,
=20
die Gruppen w=FCrde ich auch ganz anders aufteilen aber irgendwie war =
der Hr.
Teiniker von meinem Vorschlag nicht wirklich begeistert.=20
Ich bin aber pers=F6nlich auch auf jeden Fall der Meinung dass eine =
Aufteilung
wie sie Roland beschrieben hat viel zielf=FChrender w=E4re.
=20
LG
=20
Martin
=20
_____ =20
Von: tas...@li...
[mailto:tas...@li...] Im Auftrag von
Roland Walter
Gesendet: Sonntag, 08. Oktober 2006 21:37
An: tas...@li...
Betreff: [Tasktlogger-devel] Input Realisierungsans=E4tze, Architektur
=20
Hallo,
=20
bin ganz beim Martin. Auch wenn der Umfang des Projektes =84klein=93 ist =
m=FCssen
einige Definitionen getroffen werden, welche bei einem gr=F6=DFeren =
Projekt
nicht viel
anders aussehen.
=20
Nur ein paar Anregungen:
* In welche Schichten wird die Anwendung aufgeteilt=20
* (Vorschlag f=FCr Projektgr=F6=DFe BusinessLogic mit Persistenzmethoden =
und
Oberfl=E4che)=20
* Namenskonventionen (Anwendung, Datenbank, Programmfiles,
Ordnerstruktur)=20
* Oberfl=E4chentemplate=20
* Wo werden Aktionsbuttos positioniert=20
* Wie sieht die Optik der Detail und =DCbersichtsseite aus=20
* Wo werden welche CSS Klassen eingesetzt=20
* Benennung =DCbersichtsseite, Detailseite und Auswertungsseiten,
Ordnerstruktur=20
usw.
=20
=20
Da es unser Ziel als Gruppe ist, die Aufgabenstellung zu l=F6sen, wei=DF =
ich
nicht in wie weit wir dabei selbst Entscheidungen treffen k=F6nnen.
Mein Vorschlag w=E4re eine ganz andere Projektstruktur, welche aus =
meiner
Erfahrung sehr gut funktioniert.
Somit w=FCrde ich die Gruppen wie folgt ausrichten:
* Gruppe A: Integration=20
* Gruppe B: Projektvorgaben (Namenskonventionen=85),
Oberfl=E4chentemplates, DB Modell (Aufbau und Betreuung bei =
=C4nderungen)=20
* Gruppe C: Businesslogic + Persistenz f=FCr Objekte sicherstellen.=20
* Gruppe D: Oberfl=E4chenentwicklung und Visualisierung der Auswertungen
(Auswertungslogik klarerweise in Businesslogic)=20
=20
=20
Dadurch h=E4tten alle Teams klare Aufgaben und jedes Team hat seinen =
Bereich
wo es sich bewegt, anstatt dass jedes Team alle Schichten abbilden
muss. Weiters w=FCrden die Schnittstellen unter den Teams wesentlich =
kleiner
werden und die Koordination vereinfacht. Jedes Team sollte in jedem Fall
einen Verantwortlichen f=FCr die Abkl=E4rung der Schnittstellen zwischen =
den
Teams ernennen.
=20
So, ich hoff jetzt gibt=92s mal ne Diskussion =FCber das Thema ;o)
=20
LG
Roland
|
|
From: Martin K. <mar...@gm...> - 2006-10-08 19:43:20
|
Hi, =20 die Gruppen w=FCrde ich auch ganz anders aufteilen aber irgendwie war = der Hr. Teiniker von meinem Vorschlag nicht wirklich begeistert.=20 Ich bin aber pers=F6nlich auch auf jeden Fall der Meinung dass eine = Aufteilung wie sie Roland beschrieben hat viel zielf=FChrender w=E4re. =20 LG =20 Martin =20 _____ =20 Von: tas...@li... [mailto:tas...@li...] Im Auftrag von Roland Walter Gesendet: Sonntag, 08. Oktober 2006 21:37 An: tas...@li... Betreff: [Tasktlogger-devel] Input Realisierungsans=E4tze, Architektur =20 Hallo, =20 bin ganz beim Martin. Auch wenn der Umfang des Projektes =84klein=93 ist = m=FCssen einige Definitionen getroffen werden, welche bei einem gr=F6=DFeren = Projekt nicht viel anders aussehen. =20 Nur ein paar Anregungen: * In welche Schichten wird die Anwendung aufgeteilt=20 * (Vorschlag f=FCr Projektgr=F6=DFe BusinessLogic mit Persistenzmethoden = und Oberfl=E4che) * Namenskonventionen (Anwendung, Datenbank, Programmfiles, Ordnerstruktur) * Oberfl=E4chentemplate * Wo werden Aktionsbuttos positioniert * Wie sieht die Optik der Detail und =DCbersichtsseite aus * Wo werden welche CSS Klassen eingesetzt * Benennung =DCbersichtsseite, Detailseite und Auswertungsseiten, Ordnerstruktur usw. =20 =20 Da es unser Ziel als Gruppe ist, die Aufgabenstellung zu l=F6sen, wei=DF = ich nicht in wie weit wir dabei selbst Entscheidungen treffen k=F6nnen. Mein Vorschlag w=E4re eine ganz andere Projektstruktur, welche aus = meiner Erfahrung sehr gut funktioniert. Somit w=FCrde ich die Gruppen wie folgt ausrichten: * Gruppe A: Integration * Gruppe B: Projektvorgaben (Namenskonventionen=85), Oberfl=E4chentemplates, DB Modell (Aufbau und Betreuung bei = =C4nderungen) * Gruppe C: Businesslogic + Persistenz f=FCr Objekte sicherstellen. * Gruppe D: Oberfl=E4chenentwicklung und Visualisierung der Auswertungen (Auswertungslogik klarerweise in Businesslogic) =20 =20 Dadurch h=E4tten alle Teams klare Aufgaben und jedes Team hat seinen = Bereich wo es sich bewegt, anstatt dass jedes Team alle Schichten abbilden muss. Weiters w=FCrden die Schnittstellen unter den Teams wesentlich = kleiner werden und die Koordination vereinfacht. Jedes Team sollte in jedem Fall einen Verantwortlichen f=FCr die Abkl=E4rung der Schnittstellen zwischen = den Teams ernennen. =20 So, ich hoff jetzt gibt=92s mal ne Diskussion =FCber das Thema ;o) =20 LG Roland |
|
From: Roland W. <wal...@gm...> - 2006-10-08 19:38:26
|
Hallo, =20 bin ganz beim Martin. Auch wenn der Umfang des Projektes =84klein=93 ist = m=FCssen einige Definitionen getroffen werden, welche bei einem gr=F6=DFeren = Projekt nicht viel anders aussehen. =20 Nur ein paar Anregungen: * In welche Schichten wird die Anwendung aufgeteilt=20 * (Vorschlag f=FCr Projektgr=F6=DFe BusinessLogic mit Persistenzmethoden = und Oberfl=E4che) * Namenskonventionen (Anwendung, Datenbank, Programmfiles, Ordnerstruktur) * Oberfl=E4chentemplate * Wo werden Aktionsbuttos positioniert * Wie sieht die Optik der Detail und =DCbersichtsseite aus * Wo werden welche CSS Klassen eingesetzt * Benennung =DCbersichtsseite, Detailseite und Auswertungsseiten, Ordnerstruktur usw. =20 =20 Da es unser Ziel als Gruppe ist, die Aufgabenstellung zu l=F6sen, wei=DF = ich nicht in wie weit wir dabei selbst Entscheidungen treffen k=F6nnen. Mein Vorschlag w=E4re eine ganz andere Projektstruktur, welche aus = meiner Erfahrung sehr gut funktioniert. Somit w=FCrde ich die Gruppen wie folgt ausrichten: * Gruppe A: Integration * Gruppe B: Projektvorgaben (Namenskonventionen=85), Oberfl=E4chentemplates, DB Modell (Aufbau und Betreuung bei = =C4nderungen) * Gruppe C: Businesslogic + Persistenz f=FCr Objekte sicherstellen. * Gruppe D: Oberfl=E4chenentwicklung und Visualisierung der Auswertungen (Auswertungslogik klarerweise in Businesslogic) =20 =20 Dadurch h=E4tten alle Teams klare Aufgaben und jedes Team hat seinen = Bereich wo es sich bewegt, anstatt dass jedes Team alle Schichten abbilden muss. Weiters w=FCrden die Schnittstellen unter den Teams wesentlich = kleiner werden und die Koordination vereinfacht. Jedes Team sollte in jedem Fall einen Verantwortlichen f=FCr die Abkl=E4rung der Schnittstellen zwischen = den Teams ernennen. =20 So, ich hoff jetzt gibt=92s mal ne Diskussion =FCber das Thema ;o) =20 LG Roland |
|
From: Teiniker E. <Ego...@fh...> - 2006-10-08 19:16:31
|
Hallo miteinander, so wie es aussieht sind jetzt alle als Developer registriert. Das hat super funktioniert - nur weiter so! Ich habe auf der eLearning Plattform unter 'Software Engineering 3/doc' = ein neues Dokument (Iteration1-Organisation) abgelegt, in dem ich die = T=E4tigkeiten f=FCr die erste Iteration zusammengefa=DFt habe. Wenn es = Fragen gibt, bitte gleich an die Mailing-List posten. Mit freundlichen Gr=FC=DFen Egon Teiniker |
|
From: Martin K. <mar...@gm...> - 2006-10-08 19:12:07
|
Hallo zusammen, ich glaube wir sind uns einig dass wir uns vor dem Beginn der Implementierung ueber diverse Punkte der Architektur / DB-Struktur usw. ZUSAMMEN Gedanken machen muessen um uns auf eine gemeinsame Vorgehenswiese zu einigen da ansonsten nur ein riesiges Durcheinander herauskommt. Ich schlage deshalb vor dass von jeder Entwicklungsgruppe 1 Mitglied nominiert wird der sich um die Architketur / DB-Struktur und aehnliches kuemmert. Innerhalb jeder Gruppe koennen die Vorstellungen ausdiskutiert werden und dann ueber den Vertreter der Gruppe kommuniziert werden. Die jeweiligen Vertreter der 3 Gruppen vereinbaren dann die allgemeinen Richtlinien etc. an die sich alle Gruppen zu halten haben. Das sollte dann aber relativ rasch ueber die Buehne gehen damit die tatsaechliche Implementierung der User-Stories nicht behindert wird. Was haltet Ihr davon bzw. wie koenntet Ihr Euch eine Organisation dieser technischen Infrastruktur vorstellen? Bitte um Rueckmeldung/Anregungen/Kritik! LG Martin |
|
From: Manuel E. <ma...@pe...> - 2006-10-08 19:09:29
|
Hallo, =20 es haben beide Mails funktioniert.=20 =20 Um ein Antwortmail an die Liste zu verfassen muss man "Alle Antworten" w=E4hlen. Dies vergisst man oft bei Mailinglisten. =20 Das Archiv gibts unter: http://sourceforge.net/mailarchive/forum.php?forum=3Dtasktlogger-devel Es wird nur alle paar Stunden aktualisiert. =20 lg Manuel _____ =20 Von: tas...@li... [mailto:tas...@li...] Im Auftrag von Walenta Helmut Gesendet: Sonntag, 08. Oktober 2006 21:07 An: SWE_Verteiler Betreff: [Tasktlogger-devel] Zweiter Test Noch ein Test, da es vorher bei mir und eventuell=20 auch bei anderen nicht funktioniert hat. =20 gr=FCsse Helmut |
|
From: Walenta H. <Hel...@fh...> - 2006-10-08 19:07:14
|
Noch ein Test, da es vorher bei mir und eventuell=20 auch bei anderen nicht funktioniert hat. gr=FCsse Helmut |
|
From: Sabine S. <s_s...@ya...> - 2006-10-08 16:44:59
|
Just a test ;) |
|
From: Rainer S. <rai...@fh...> - 2006-10-08 09:57:13
|
Hallo, Gruppe C: Martin Kuhn Thomas Pratter Sabine Seifriz Rainer Smekal (Sprecher) Helmut Walenta lg Rainer |
|
From: Manuel E. <ma...@pe...> - 2006-10-08 09:11:51
|
Hier noch ein Subversionclient f=FCr Windows welcher sich im = Kontextmen=FC im Windows Explorer bedienen l=E4sst: http://tortoisesvn.tigris.org/ =20 lg Manuel _____ =20 Von: tas...@li... [mailto:tas...@li...] Im Auftrag von Pratter Thomas Gesendet: Samstag, 07. Oktober 2006 21:59 An: tas...@li... Betreff: [Tasktlogger-devel] subversion plugin f=FCr eclipse hallo, f=FCr alle die es nicht kennen: http://subclipse.tigris.org/ lg, thomas=20 |
|
From: Walenta H. <Hel...@fh...> - 2006-10-08 08:47:50
|
Ich habe mich im Verteiler angemeldet. Hoffendlich hat es funktioniert, und ich bekomme ab sofort=20 eure Mails auch zugeschickt! gr=FCsse helmut |
3 messages has been excluded from this view by a project administrator.
