Zum Inhalt springen

test_nick

Mitglieder
  • Gesamte Inhalte

    10
  • Benutzer seit

  • Letzter Besuch

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

  1. Vielen Dank erstmal für das Feedback. Könnte mir jemand von euch noch eine Strategie erläutern, wie man am besten eine Variation des Wasserfall-Modells unterbringt, indem man testgetrieben entwickelt, aber trotzdem nicht den unten aufgeführten "Product Backlog" von z.B. Scrum anfügen muss. Eigentlich funktioniert die testgetriebene Entwicklung mit dem Wasserfall-Modell nicht, oder?
  2. Bezogen auf die Projektdoku: In diesem Punkt gebe ich dir natürlich Recht. Das sollte ich dann auf jeden Fall ergänzen. Bezüglich des SOLL-Zustands: Dieser wird von der GF über die jeweilige Verknüpfung Qualfikation + Stelle festgelegt. Der Zustand "Gewünscht" kann von jedem Mitarbeiter individuell festgelegt werden, wenn er sich z.B. in einem bestimmten Gebiet gerne fortbilden würde. Und zu letzt: Der vermeintlich Overkill: Ich persönlich finde, dass es schon gut ist, wenn man einen Überblick über die aktuelle Teamlage hat. Weiterhin war dies laut der GF eine Anforderung, die durch die ISO-Zertifizierung entstanden ist. Wir hatten versucht, dass ganze simple in einer Excel-Tabelle abzubilden, sind dann aber daran gescheitert, da uns die Flexibilität bzgl. der Darstellung und der sinnvollen Verwaltung etwas gefehlt hat.
  3. Vielleicht sollte ich das kurz zwischenschieben, da es vielleicht nicht aus dem Projektantrag herausgeht: Wir sind ein Kleinunternehmen mit ca. 10-15 Mitarbeitern - in unserem Fall hat die gesamte HR (1 Person + GF) sowieso Zugriff auf sämtliche personenbezogenen Daten und erhebt und verarbeitet diese auch. Natürlich hast du Recht - wenn man das Projekt für größere Unternehmen mit unterschiedlichen Voraussetzungen umsetzen würden. Da ich aber diesen Anwendungsfall bei uns nicht sehe bzw. die Umsetzung ja schon für das jeweilige Unternehmen realitätsnah bzw. nicht "künstlich komplexer" gemacht werden soll, denke ich, dass wir in unserem Falle mit diesen zwei Rollen auskommen sollten. Ich bin da der Meinung, dass man Dinge nicht komplexer machen sollte, als man sie tatsächlich wirklich benötigt.
  4. Ich verstehe dein Anliegen. Vielleicht hatte ich mich etwas falsch ausgedrückt - deshalb hier noch etwas konkreter, was ich genau meinte: Grundsätzlich dürfen "Mitarbeiter", "Berufe" und "Qualifikationen" lediglich von der GF angelegt werden. Diese dürfen auch alle Mitarbeiter und das gesamte Team samt Qualfikation einsehen sowie verändern. Ein einzelner Mitarbeiter jedoch darf lediglich nur seine Details einsehen und Änderungen am Status "Gewünscht" in der jeweiligen Qualifikation ändern. Daten am "IST" und "SOLL" Qualfikationsstatus können von Mitarbeitern nicht verändert werden. Weitere Daten dürfen aus Datenschutzgründen nicht von den Mitarbeitern eingesehen werden. Daraus ergeben sich für mich zwei Rollen: Administrator – Geschäftsleitung Benutzer – Mitarbeiter
  5. @Chief Wiggum: Naja - ich würde das ganze so sehen: Entweder man darf alle Mitarbeiterdaten einsehen und des Teams ("Geschäftsführung") oder ich darf lediglich mein eigenes Profil ("Mitarbeiter") einsehen. Hast du da an etwas anderes gedacht oder übersehe ich vielleicht einen Punkt, der für die korrekte Realisierung erforderlich ist?
  6. In diesem Punkt hast du natürlich Recht - das Berechtigungssystem fehlt tatsächlich in der Implementierungsphase - wobei hier zwei triviale Rollen reichen sollten. Um alles weitere wurde sich schon von der Geschäftsführung gekümmert.
  7. Danke @Saheeda. Das stimmt tatsächlich - das macht einfach wenig Sinn. Ich passe das entsprechend an!
  8. @mapr: Ging leider nicht mehr, vermutlich weil die Zeit abgelaufen war. Der Antrag ist nun im Post von eben
  9. Klar, sorry - wusste nicht, dass man das nicht darf. 1 Projektbeschreibung Im Rahmen der Zertifizierung der xXx nach ISO 9001 und der damit zugehörigen Prozessoptimierungen soll eine Webanwendung zur Mitarbeiterbeurteilung entwickelt werden, welche durch eine Qualifikationsmatrix einen Überblick über die vorhandenen, gewünschten und auf- zubauende Zustände von einzelnen Mitarbeitern und der verschiedenen Abteilungen ermittelt und anschaulich darstellt. 1.1 Ist-Analyse Derzeit wird der Status der aktuellen, gewünschten und aufzubauenden Kompetenzen der einzelnen Mitarbeiter und des gesamten Teams nicht dokumentiert. Die fehlende Dokumentation führt zu einer unübersichtlichen Situation bei der Einweisung von neuen Mitarbeitern, weil nicht eindeutig definiert ist, welcher Mitarbeiter die jeweilige Person in die unterschiedlichen Bereiche einweisen kann. 1.2 Soll-Konzept und Ziele Um die Qualifikationssituation der jeweiligen Mitarbeiter und des gesamten Teams zu erfassen und nicht zuletzt damit eine Einweisung für neue Mitarbeiter effizienter gestaltet werden kann, soll eine Webanwendung mit grafischer Oberfläche und eine Datenbank entwickelt werden. Durch die prozess- orientierte Optimierung können folglich Zeit und Kosten eingespart werden. Durch die Entwicklung der Applikation ist eine Steigerung der Zufriedenheit der Mitarbeiter zu erwarten, weil dadurch die gewünschten beruflichen und persönlichen Bedürfnisse besser gefördert werden können. 2 Projektdurchführung 2.1 Anforderungen und Implementierungsdetails Das nach dem Wasserfall-Modell zu entwickelnde Projekt soll nach der Erstellung des Pflichtenhefts aufgrund von architektonischer Entscheidungen im Unternehmen serverseitig mit PHP und daten- banktechnisch mit MySQL umgesetzt werden. Damit auch nachhaltig auf neue Anforderungen der Software schnell reagiert werden kann und dies keine Beeinflussung auf die bestehende Applikation hat, soll die Lauffähigkeit durch automatisierte Tests gewährleistet werden und die Techniken des Continuous Integration-Vefahrens eingesetzt werden. Für die Versionsverwaltung soll Git in Verbin- dung mit GitHub verwendet werden. Der Projektfortschritt soll – wie betriebsintern üblich – durch das Projektmanagementtool Asana dokumentiert werden. Eine bereits bestehende Jenkins-Instanz er- möglicht das Continuous Integration-Verfahren. Die entwickelte Anwendung muss am Ende auf einem betriebsintern üblichen LAMP-Stack lauffähig sein. 2.2 Projektschnittstellen Da es sich um ein betriebsinternes Projekt handelt, trägt die xXx die Mittel zur Umsetzung des Projekts. Die Hauptnutzergruppe der Anwendung ist die Geschäftsleitung der xXx. Darüber hinaus sollen alle Mitarbeiter Zugang zum eigenen aktuellen Kompetenzprofil haben und den gewünschten Kompetenzzustand hinterlegen können. 2.3 Zeitplan Planungs- und Analysephase 6,5h 1. Analyse des Ist-Zustands 0,5 h 2. Soll-Konzept 1,75 h 3. Lastenhefterstellung 2,25 h 4. Wirtschaftslichkeitsanalyse und Amortisierung 1 h 5. Anwendungsfalldiagramm erstellen 1 h Entwurfsphase 13 h 1. Prozessmodellierung 1,5 h 2. Datenbankentwuf 3 h 2.1. ER-Modell 1,5 h 2.2. Datenbankmodell erstellen 1,5 h 3. Benutzoberflächen entwerfen 3,5 h 3.1. Bleistiftskizzen 0,5 h 3.2. Mockups 3 h 4. Planung der Architektur mit UML-Klassendiagramm 2 h 5. Erstellen des Pflichtenhefts 3 h Implementierungsphase 26 h 1. Anlegen der Projektdaten 2,5 h 1.1. Datenbankanlage 0,25 h 1.2. Docker-Container 0,5 h 1.3. IDE-Projekt/GitHub-Projekt anlegen 0,25 h 1.4. Einrichten der statischen Code-Analyse 0,5 h 1.5. CI-Einrichtung 1,0 h 2. Umsetzung der Oberflächen mit HTML/CSS 2 h 3. Datenbank-Struktur implementieren 2 h 4. Implementieren der Geschäftslogik 19,5 h 4.1. Implementierung von CRUD für Mitarbeiter, Berufe, Kompetenzen 3 h 4.2. Programmierung der SOLL/IST-Kompetenzsituation 3 h 4.3. Implementierung der Übersichts-Ansicht für Teams 5,5 h 4.5. Programmierung der Ansicht für einzelne Mitarbeiter 3 h 4.4. Programmierung einer Vergleichsansicht für den Positionswechsel 5 h Qualitätsmanagement 13 h 1. Automatisierte Tests 8 h 1.1. Erheben von möglichen Test-Cases 1 h 1.2. Implementierung von Unit-/Integrations- und Akzeptanztests 5 h 1.3. Fehlerbehebung 2 h 2. Durchführung von Manuellel Tests 2 h 3. Code-Review mit Fachbereichsleiter 2 h 4. Deployment der Applikation zur Liveschaltung 1 h Erstellen der Dokumentationen 11,5 h 1. Projektdokumentation 8 h 2. Generieren der Entwicklerdokumentation mit PHPDoc 1 h 3. Anwenderdokumentation 2,5 h Gesamt 70
  10. Hallo Leute, im Zuge meiner Ausbildung zum FIAE muss ich jetzt bis zum 10.01.2019 den Antrag zum Projekt bei der IHK Düsseldorf abgeben. Da ich so etwas noch nicht gemacht habe, denke ich, dass es ganz gut wäre, wenn ihr Euch den Antrag noch einmal angucken könntet und dann ggfs. Verbesserungsvorschläge geben könntet. 1. Zum Beispiel war ich mir unsicher bei der Verfahrensweise: Ich würde das Projekt am liebsten testgetrieben umsetzen - weiß aber nicht ganz genau wie ich das mit dem Wasserfall-Modell am besten verheiratet bekomme, da ich ansonsten laut der IHK Düsseldorf den "Product Backlogs" enthalten. Dort heißt es nämlich: 2. Ebenso bin ich mir noch unsicher, ob ich vielleicht noch eine Nutzwertanalyse bzgl. der Backend-Framework Wahl mit unter bringen sollte, damit das Kriterium auch noch bewertet werden kann. Grüße Jan

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...