TU Praxissemester Aufgabenbeschreibung

Transkript

1 TU Praxissemester Aufgabenbeschreibung

2 Aufgabenübersicht 1.Portalvergleich 2.Entkoppelte intelligente Suche

3 Portalvergleich 1/2 Problemstellung Der LifeRay-Server gilt als defacto Standard zur Erstellung von Portalen im OpenSource Bereich. Schwergewichtiger Server mit entsprechendem Overhead im Betrieb und der Entwicklung Langsam veraltende Portalspezifikation und -technologie Aufgabenbeschreibung Evaluieren von leichtgewichtigen LifeRay/Portalserver Alternativen, welche insbesondere neuere Technologien einbeziehen (z.b. HTML5, REST, Websockets) Lösungsansatz, Architektur und Prototyp für 1-2 Alternativen erstellen

4 Portalvergleich 2/2 Aufgabenumfang 1. Identifizieren der notwendigen Portalbestandteile (z.b. Authentifizierung, Content-Life-Cycle, Integration externer Systeme, etc.) 2. Aufführen neuerer einzubindender Technologien 3. Ermitteln von LifeRay-Portalserver Alternativen 4. Auswahl von 2 Alternativen (Vergleichsdarstellung und Auswahlbegründung) 5. Erstellen einer Architektur für die gewählten Alternativen 6. Erstellen je eines Prototypen

5 Intelligente Suche 1/2 Problemstellung Jeder Website Besucher erwartet heutzutage eine intelligente Suche á la Google Kommerzielle mächtige Suchen sind oft zu teuer Solr bietet eine ebenso mächtige OpenSource Alternative, welche allerdings schon in der Grundkonfiguration nicht trivial zu nutzen ist Das Integrieren einer Suche in eine bestehende Website erfordert meist einen hohen Aufwand Aufgabenbeschreibung Erstellen einer sinnvollen generischen Grundkonfiguration für Solr Einfache und schnelle Integrationsfähigkeit von Solr in Websites herstellen

6 Intelligente Suche 2/2 Aufgabenumfang 1. Erstellen einer autark koppelbaren Suchplattform auf Solr Basis (eigenständig laufende (clusterfähige) VM) 2. Erstellen einer sinnvollen Grundkonfiguration (bzgl. Stemming, Caseing, Marker, etc.) 3. Erstellen einer abstrahierten (REST-) API für die wesentlichen Funktionen Indizierung, Suggestions, Facetten, Meinten Sie, andere Nutzer suchen auch, ggf. Boosting 4. Einfache Möglichkeit Facetten für Subdomains, Bereiche oder sonstige inhaltliche Cluster einzubinden 5. Auswertungsmöglichkeit von Suchanfragen (z.b. Top 100 des letzten Monats) > Testobjekt stellt die TU Website, mit ihren Unterbereichen dar

7 Funktionale Erweiterung von GovData Projekt im Rahmen des Praxisprojekts Anwendungssysteme an der TU Berlin, WiSe2014/15

8 Open (Government) Data -Was bedeutet das überhaupt? -

9 Open (Government) Data?!? OffeneDaten sind Daten, die von OffeneDaten sind Daten, die von jedermann frei benutzt, weiterverwendet und geteilt werden können -die einzige Einschränkung betrifft die Verpflichtung zur Nennung des Urhebers. (opendefinition.org)

10 Zehn Prinzipien für offene Daten* 1. Vollständigkeit 2. Primärquellen 3. Zeitliche Nähe 4. Leichter Zugang 5. Maschinenlesbarkeit 6. Diskriminierungsfreiheit 7. Verwendung offener Standards 8. Offene Lizenzierung 9. Dauerhaftigkeit 10. Kostenfreiheit * basierend auf den Kriterien der Sunlight Foundation (

11 Daten und Informationen sind wesentliche Ressourcen einer Informationsgesellschaft. Bildquelle -Titelseite der Berliner Open Data Strategie

12 Der Nutzen offener Daten kann vielfältig sein Wirtschaftlicher Nutzen Bürger-Nutzen Staatliche Transparenz Verwaltungs-Nutzen

13 GovData Prototyp für ein ebenenübergreifendes Datenportal

14 GovData aggregiert die Beschreibungen von Daten aller Verwaltungsebenen und macht sie an zentraler Stelle auffindbar Behörde A Behörde B Datenkatalog I Datenkatalog II OffeneDaten.de Behörde C Datenkatalog III Behörde D

15 Wichtig: GovData ist ein reine Metadatenkatalog die Datensätze bleiben immer bei den Bereitstellern! Behörde A Datenkatalog I Datensatz OffeneDaten.de

16 Die Projektvorschläge

17 Worum geht es eigentlich? Konzeptionelle Ausarbeitung von einem von zwei Ansätzen zur funktionalen Erweiterung von GovData Beide Ansätze sind wichtig für den weiteren Ausbau des Portals und damit für die Verbreitung der Open Data -Idee in Deutschland Für die teilnehmenden Studierenden: Einstieg in Themenfeld Open (Government) Data praktische Erfahrungen in einem innovativen, Bund- Länder-übergreifenden Projekt mit hoher politischer Bedeutung

18 Ansatz 1: Kartenbasierte Daten-Suche Auswertung der GovData-internen Suche zumeist geografische Suchbegriffe GovData-Metadatenstruktur sieht solche Angaben vor Aber: Portal bietet derzeit keine entsprechende kartenbasierte Suche Zeige alle Daten, die die Stadt Ulm bereitstellt Zeige alle Daten, die sich auf die markierte Region beziehen Projektziel: Konzeption dieser Suchfunktionalität Konzeption einer Vereinheitlichung der verschiedenen Varianten zur Angabe des Raumbezugs

19 Ansatz 1: Kartenbasierte Daten-Suche (Beispiel) Bildquelle Screenshot der kartenbasierten Suche von

20 Ansatz 2: Datenvisualisierung Grundprinzip von Open Data: maschinenlesbare Rohdaten geeignet für Daten-Weiterverwender (Entwickler, Datenjournalisten, Statistiker etc.) Interesse bei anderen Teilen der Bevölkerung aber auch: auswertete und visualisierte Daten Flexible Preview, Auswertung und/oder Visualisierung von Daten bisher nicht möglich Projektziel: Untersuchung von verfügbaren Werkzeugen auf ihre Tauglichkeit Konzeption zur Einbindung eines geeigneten Werkzeugs in GovData

21 Ansatz 2: Datenvisualisierung (Beispiel) Bildquelle Screenshot der site usage -Auswertung von

22 Projektorganisation und Ergebnisform Ansprechpartner: Verantwortlicher Projektleiter: Jan-Ole Beyer (Referat O1, BMI) technische Fragestellungen: wird zum Start benannt Bedarfsweise Vermittlung weiterer Ansprechpartner durch BMI Projektmeilensteine und -termine Kick-Off-Meeting zum Start des Projekts Zwischenpräsentation Mitte Dezember im BMI Abschlusspräsentation im Februar regelmäßige joursfixes zwischen Projektteam und BMI weitere Termine: Abstimmung zwischen BMI und Projektteam zum Start Ergebnisse: Foliensätze für beide Präsentationstermine Abschlussbericht

23 Voraussetzungen Zwingend: Interesse an der Auswertung/Visualisierung von Daten am Thema Open (Government) Data an der Arbeit in einem ebenenübergreifenden, innovativen Projekt der öffentlichen Verwaltung Von Vorteil: Erfahrung im Thema Open Data, insbesondere unter Zuhilfenahme von existierenden (webbasierten) Open- Source-Produkten mit den Softwarekomponenten CKAN und Liferay Portal Hifreich im Blick auf eine Umsetzung von Ansatz 1 Java-Kenntnisse

24 <ende> Jan-Ole Beyer Referat O1 Bundesministerium des Innern Alt-Moabit 101d, Berlin

25 Integrierte Geschäftsmodell- und Produkt-Entwicklung Anselm Busse Fachgebiet Kommunikations- und Betriebssysteme

26 Business-Model-oriented Technology Development Process Flow Model (Sample Overview) Ausgangslage Business Models Customer Development Agile Framework Product Development Technical Roadmap Organisational Roadmap Release Plans Code Hardware User Stories Requirements Business Plans Customer Interviews Minimal Viable Products Architecture Tests Models Tool Chain CanvEd 12 Integrierte Geschäftsmodell- und Produkt-Entwicklung A. Busse Berlin Seite 2 CR/AEY1-B&T-Team Mar 2014 Robert Bosch GmbH Alle Rechte vorbehalten, auch bzgl. jeder Verfügung, Verwertung, Reproduktion, Bearbeitung, Weitergabe sowie für den Fall von Schutzrechtsanmeldungen.

27 Projektinhalt Das Projekt wird in Kooperation mit der Robert Bosch GmbH durchgeführt: Integrierte Produkt- und Geschäftsmodellentwicklung Modellbasierter Informationsaustausch zwischen Prozessschritten Ontologie Tool-Integration (REST-kompatible Schnittstellendefinition) Start-Ups als Vorbild Transfer von Vorgehensweisen Hoch agile Entwicklung (Fallstudien) Integrierte Geschäftsmodell- und Produkt-Entwicklung A. Busse Berlin Seite 3

28 Kontakt bei Rückfragen: Anselm Busse 030/ Raum EN356 Integrierte Geschäftsmodell- und Produkt-Entwicklung A. Busse Berlin Seite 4

29 TU Berlin PAS Project: Time capsuling system DHL Express Berlin, October 13, 2014

30 Issue DHL Express Europe is forced to retain a system which is technical and operational legacy for five more years. Once the replacement project has delivered in three to five years the system (including all interfacing target and source systems) has to be decommissioned. At that time key stakeholders are expected to have retired and will be unavailable for knowledge transfer! final presentation: DHL (Bonn) Page 2

31 Task Support DHL Express Europe IT by proposing a set of documents necessary to retain the system today and enabling a future team to understand and decommission the system after three years without access to current stakeholders. final presentation: DHL (Bonn) 13/10/2014 Page 3

32 Deliverables A case study of how knowledge capture was conducted in the case. A review on the state of the scientific and technical knowledge about system legacy development and evolution, legacy system knowledge capture and computer language documentation of already outdated procedural language in use today. A set of guiding principles to help plan and implement the knowledge capture in the case. final presentation: DHL (Bonn) 13/10/2014 Page 4

33 Student project Requirements OMICRON as part of Praxisprojekt Anwendungssysteme at TU Berlin Berlin, Germany 13 October 2014

34 OMICRON OMICRON is an international company providing innovative testing, diagnosis and monitoring solutions for electrical power systems. Our products and services allow a realistic and accurate assessment of the condition of power system assets. OMICRON Page 2

35 Requirements OMICRON > We are a company with a focus on innovations > We have to handle a lot of requirements for complex products The content of the project is: > Analyze the current state of Requirements Management regarding > Documentation > Traceability > Collaboration > Identify room for improvement regarding the current state > Develop recommendations OMICRON Page 3

36 Expected outcomes > Intermediate presentation and report on the state-of-practice (December) > Final report (February): > Structured analysis of requirements management practice at OMICRON > Identification of shortcomings and room for improvement > Development of recommendations to address the shortcomings and to improve current practice > Final presentation (March): > Summary of the project and the most important lessons learned > Next steps that the company may take > Critical reflection of both the student project (organization and management) and the content of the project (the actual requirements management practice) OMICRON Page 4

37 Significance of the student project for OMICRON > OMICRON depends on a properly working innovation process > Requirements Management is a very important part of the innovation process > To ensure long-term success of our innovation projects we need to improve our processes continuously > We expect the student project to help us to identify shortcomings and to improve our requirements management practice OMICRON Page 5

38 Significance of the student project for students You have the chance to > work with experts of an international company > improve your analytical skills > enlarge your expertise about Requirements Management > work self dependent in a small project OMICRON Page 6

39 Organization & Communication > Project duration: October 2014 March 2015 (Berlin) > The project includes 3 main milestones: > Kick-Off-Meeting (October) > Intermediate presentation (December) > Final presentation (March) > Appointments with OMICRON experts will need to be organized during the project > Both OMICRON and the project team define a primary contact person for communication > A detailed project plan (including deliverables) will be defined and agreed upon in the Kick-Off-Meeting OMICRON Page 7

40 Your Profile > Interested in process development in an international company > Motivated to perform and to succeed > Responsible, structured and project-oriented way of working > Communicative team player with excellent organizational skills > Strong analytical skills > Good command of English is preferred OMICRON Page 8

41 Hopefully you are inspired by this project > For more information you can visit our website OMICRON Page 9