Chance für Informatikstudentinnen

Google Europe Anita Borg Memorial Scholarship 2007

Ihr erinnert Euch doch an den "Summer of Google"? Hier kommt noch einmal ein Angebot im Gedächtnis an Anita Borg. Achtung, die Deadline ist

Freitag, 12. Jan. 2007

Beate List, die auch bei der letzten IF in Bremen zu Gast war, hat diese Ausschreibung zum Jahresende ausgesendet. Sie lautet wie folgt:

Dear Informatik Students,

As part of Google’s ongoing commitment to encourage women to excel in computing and technology, we are pleased to announce the Google Europe Anita Borg Memorial Scholarship 2007. This is a EUR 5,000 (or equivalent) scholarship for the 2007/2008 academic year and the deadline for submission is Friday, January 12th, 2007. You can find more details at
http://www.google.com/anitaborg-europe/.

The Google Anita Borg Memorial Scholarship first launched in the US in 2004. Since then, over thirty scholarships have been awarded. We hope to make the Google Anita Borg Memorial Scholarship in Europe as successful as it has been in the US and would like your help in doing so.

Can you help spread the word by sending out the below email to your BSc, MSc, and PhD students? We have also included an attachment for you to pass to your students. The scholarship is for female students studying Computer Science, Computer Engineering, Informatics or related technical fields.

We created posters to help promote this opportunity and it would be great if we could send some along to you. If this is fine with you, please let me know the best mailing address to use.

Thank you for your help and we hope to see many students participate.

Best regards,
Beate

http://www.google.ch/jobs/

Subject line: Google Europe Anita Borg Memorial Scholarship 2007

Dr. Anita Borg (1949 – 2003) devoted her adult life to revolutionising the way we think about technology and dismantling barriers that keep women and minorities from entering computing and technology fields.

As part of Google’s ongoing commitment to furthering Anita’s vision, we are pleased to announce the Google Europe Anita Borg Memorial Scholarship 2007. Through the scholarship, we aim to encourage women to excel in computing and technology, and become active role models and leaders. A group of female BSc, MSc, and PhD student finalists will be chosen from the applicant pool. The scholarship recipients, selected from the finalists, will each receive a EUR 5,000 (or equivalent) scholarship for the 2007/2008 academic year.

Eligibility Requirements

Candidates must:

• be a female student entering her final year of a BSc, or enrolled in an MSc or PhD programme (or equivalent) in 2007/2008
• be enrolled in full-time study at a University in Europe. Citizens, permanent residents, and international students are eligible to apply
• be studying Computer Science, Computer Engineering, Informatics, or a related technical field
• maintain an excellent academic record (e.g. a First Class Honours degree)

For complete details, please visit
http://www.google.com/anitaborg-europe/

All applications must be received by Friday, January 12, 2007.

Liebe Leserinnen (und Leser), ich erwarte, dass wir bald expandieren, Richtung USA und weltweit – wo auch immer Ihr nach Eurer Bewerbung landet. Bewerbt Euch. Glaubt an Euch. Das tun wir von der Redaktion auch! (Und schickt dann einen Erlebnisbericht an die Zeitung, so isses gedacht…)

nach oben

 Maria

von Maria

… und sprich mit der Entwicklerin

Anfang Dezember hatte ich das Glück, einmal ein professionelles Analytikerseminar besuchen zu dürfen. Ein paar Dinge, die ich dort gelernt habe, und ein paar Dinge, die mir dort und danach selbst (wieder) eingefallen sind, stelle ich in diesem Artikel vor.

Wenn eine neue Software entwickelt oder ein altes System modernisiert werden soll, steht erst einmal eine Analyse an: Was wird derzeit eingesetzt? Was gibt es überhaupt an Aufgaben, die mit oder ohne Software erledigt werden? Welche Wünsche an eine neue Software existieren? Und so weiter, und so fort… Für diese Phase der IT-Systementwicklung gibt es Modellierungsmethoden. Bei OOSE (www.oose.de) gibt es nicht nur den UML-Becher (s. auch die Rezension „Unified Modeling Language“ vom 7. Juni 2003), sondern auch Seminare. Völlig subjektiv sag ich hier mal, dass die klasse sind. [Anm. der Red. Natürlich nicht ganz so klasse wie die Kurse bei der IF… ;-) , aber auch sehr, sehr gut.] Kurz und gut, OOSE lehrt Methoden und Sprachen, die frau online auch beschnuppern kann. Wer noch Weiterbildung sucht, die ihr Chef für sie fordert, sollte hier mal nachsehen. Genug unbezahlte Werbung, jetzt kommt endlich ein bisschen Inhalt.

nach oben

Interviews

Am Anfang stehen die Interviews. Interviews mit Jenen, die die Software später benutzen. Worum geht es hier? Die Analytikerin will herausbekommen, welche Arbeitsabläufe überhaupt existieren. Dabei gibt es ein paar Punkte, die frau beachten kann:

• Fragen: „Welches sind die Probleme?“
• Probleme identifizieren, erst SPÄTER Lösungen überlegen
• Anzahl identischer Antworten mitzählen sowie Prioritäten protokollieren
• Interviews möglichst zu zweit mit den Interviewpartner/innen führen (dann hat man schon mal vier Ohren und zwei Sichten)

Eine Gefahr bei der Systementwicklung ist „Der goldene Hammer“. Was bedeutet das? Wer als Werkzeug nur den Hammer kennt, für den sieht alles aus wie ein Nagel. Das gilt insbesondere auch für Programmierer/Coder. So könnte es passieren, dass vorschnell Lösungen vorgeschlagen werden, die anscheinend auf der Hand liegen, ohne andere Möglichkeiten zu berücksichtigen.

nach oben

Im Gespräch bleiben und den Weg im Auge behalten

Wichtig ist die Diskussion, das Gespräch! Details gehören dazu, stehen aber nie im Mittelpunkt (in dieser Phase). Es geht darum, um was es geht! Mit dem Vorsatz, Einigkeit in der Sicht auf die Dinge zu erreichen. Das Ziel ist, das zu modellierende neue Softwaresystem für alle Beteiligten möglichst nützlich und brauchbar entwickeln zu können. Dafür muss frau erst mal wissen, wie der Rahmen aussieht. Details können später geklärt werden. Abstraktion ist hier das Zauberwort.

Eine Schwierigkeit bei der Analyse besteht darin, dass endlose Diskussionen und das Hinabtauchen in Detailfragen den Zeitrahmen sprengen. Was also kann die Analytikerin tun, um das Problem „Zeit einhalten“ bei Arbeitstreffen in den Griff zu bekommen?

• Den Zeitrahmen für Treffen vorgeben (und den Beteiligten vorab und mittendrin mitteilen)
• Das Bewusstsein schaffen: Irgendwann muss man entscheiden
• (Noch) offene Probleme explizit notieren
• „Stehung“ statt Sitzung

Eine Methode, Deadline-Verschiebungen zu vermeiden, ist das „time boxing“: Zeit geht vor Inhalt, d. h. die Deadlines sind fest, nicht die Ergebnisse. Das Ganze geht mit agiler Softwareentwicklung Hand in Hand. Keine Frage, so eine Vorgehensweise muss mit den Entscheiderinnen und Entscheidern abgesprochen werden! Nichtsdestotrotz ist time boxing sinnvoll:

Auftraggeber/innen kaufen lieber fertige Software, die nicht perfekt ist, als perfekte Software, die nicht fertig ist!

Ein Startpunkt jeder Modellierung ist der „gute Fall“, das bedeutet, dass Ausnahmen und Sonderfälle jetzt noch nicht betrachtet werden. Solche werden später eingefügt. Das hilft nicht nur, die Zeit einzuhalten, sondern erhöht auch die Übersichtlichkeit.

Erfolgsformel

Diese Formel habe ich von einem OOSE-Mitarbeiter gelernt – und sofort geglaubt: Erfolg = Qualität * Akzeptanz. Sie beschreibt die Abhängigkeit des Erfolgs nicht nur von der Qualität des Produkts, sondern auch von der Akzeptanz seitens der Kundschaft. Trivial? Klar, aber der eine Faktor (welcher wohl…?) wird leider immer noch viel zu oft ignoriert.

nach oben

Kreativitätsmethode „Produktkarton“

Aufgabe: Produktkarton für das fertige Produkt (SOLL) entwerfen, in dem der Benutzerin oder dem Benutzer und anderen Beteiligten das System „verkauft“ werden soll. Die Größe sollte etwa die eines Schuhkartons sein. Darauf geschrieben werden Ideen/Systemvoraussetzungen etc. Ein Beispiel ist auf dem Foto zu sehen.

• Wie heißt das Produkt? (Hier: go4IT)
• Produktfeatures: 5-15 Merkmale und Eigenschaften (im Bsp. vier Anwendungsbereiche)
• Voraussetzungen: Hardware, Softwarearchitektur, Systemumgebung/Fremdsysteme (Schnittstellen), Entwicklungswerkzeuge, organisatorische und personelle Voraussetzungen …
• Für Verkaufsprodukte: Preis

Beschreibung und Messkriterien

Zur Beschreibung bietet sich die UML an, die Unified Modeling Language. Außer den Diagrammen gibt es aber noch andere wichtige Aspekte. Wie umfangreich soll die textuelle Beschreibung einzelner Anwendungsfälle denn nun sein? Als Daumenregel kann frau sich merken: Eine Din-A4-Seite. Auch Systemidee und Ziel passen auf max. eine Din-A4-Seite (vgl. Produktkarton). Natürlich helfen bei der Umsetzung auch Kennzahlen. Sie helfen, sind aber immer auch mit Vorsicht zu genießen. Ein Beispiel aus der Nagelfabrikation: Da lautete die Kennzahl „möglichst viele Nägel pro Monat produzieren“. Was dazu führte, dass nur noch kleine Nägel hergestellt wurden. Bei der Kennzahl „Stahlverbrauch pro Monat“ dagegen kam es zur Produktion riesiger Nägel… (auch das ein Beispiel aus dem Seminar und nicht auf meinem Mist gewachsen – aber eingängig).

Was gilt es noch zu beachten? (Achtung, Ausnahmen gibt es ab und an.)

• Ist das verständlich formuliert (Sprache der Anwender/in, nicht der Entwickler/in)? Alle möglichen Leser/innen müssen die Beschreibung verstehen können!
• Substantiv und Verb
• Aus Sicht des Unternehmens bzw. des Akteurs
• Die Beschreibung ist technologieunabhängig, der Name fachlich
• Ist es ein Anwendungsfall oder nur ein Detailschritt?
• Auslöser und Ergebnis finden
• Ist das Beschriebene überhaupt relevant? (Im Zweifel erst mal aufschreiben, streichen kann frau hinterher immer noch)
• Glossar führen: Begriffe definieren

nach oben

Aus der Praxis

Hier noch ein paar Mosaiksteinchen aus der Praxis. Es gibt Organisationen, die haben für alle Softwaresysteme die Vorgabe „handschuhbedienbar“. Klingt aus meiner Sicht gut, denn ich bin zwar kurzsichtig, aber durchaus technikaffin und erlebe die Miniaturisierung der Webtexte und Links als absolut abstoßend!

Wo war ich stehengeblieben? Ach ja, Mosaiksteinchen. Präsentationen des neuen Softwarekonzepts bei der Auftraggeberin sollten zu zweit oder mehr gehalten werden. Wozu? Eine spricht, ein anderer notiert Fragen während der Präsentation, um diese später zu beantworten. Die Rollen können wechseln, das erhöht die Aufmerksamkeit des Publikums.

Etwas Psychologie kann auch nicht schaden: Haben wir es hier mit einem risikofreudigen oder einem kostenbewussten Typ zu tun? Liegt gerade ein anderes Problem in der Luft, das eigentlich nix mit der Software zu tun hat? Solche Störungen können den Erfolg einer Präsentation bekanntlich stark beeinflussen, das haben wir alle wohl schon mal erlebt.

Fazit

Modellieren ist ein Prozess, der nie abgeschlossen ist (klar, panta rhei). Modelle sind einfach Mittel, die die Kommunikation und gegebenenfalls den Konsens untersützten sollen. Viel Spaß dabei!

nach oben

Maria

von Maria