Efektywne tworzenie oprogramowania 2008/2009. Forty Years of Software Engineering Konferencja w Garmisch – 1968 50 uczestników Prof. Bauer TUM przewodniczący.

Prezentacja na temat: "Efektywne tworzenie oprogramowania 2008/2009. Forty Years of Software Engineering Konferencja w Garmisch – 1968 50 uczestników Prof. Bauer TUM przewodniczący."— Zapis prezentacji:

1 Efektywne tworzenie oprogramowania 2008/2009

2 Forty Years of Software Engineering Konferencja w Garmisch – 1968 50 uczestników Prof. Bauer TUM przewodniczący Randell i Naur – redaktorzy raportu

3 SE Garmisch 1968 Nie było w tym czasie: Komputerów osobistych Baz danych Sieci komputerowych lokalnych Internetu Powstawał ARPANET

4 ICSE 2008 Randell, Broy, Naur o konferencji w Garmisch i jej następstwach Kanada, Japonia, Wlk Brytania, Indie, Niemcy – panel na temat „Certification of Software Profesionals” http://icse08.upb.de/program/downloads.html

5 ETO – zasady (1) Obecność na wykładzie jest obowiązkowa: wstęp do pracy na ćwiczeniach (np. dzisiaj dot. stylu kodowania oraz mierzenia czasu) pierwsze 10 minut (kilkakrotnie) kartkówki aktywność, referaty prezentacja projektu wykonanego przez zespoły 40% oceny z egzaminu

6 ETO – zasady (2) Ćwiczenia/laboratorium: prace indywidualne (zadania, ewaluacja, referaty) praca zespołowa –w parach (XP) –w projekcie (zespół 3-5 osób) Praca w parach: ok. 1-3 godzin tygodniowo (2 osoby siedzą przy jednym komputerze)

7 ETO – zasady (3) Tworzenie zespołów: najlepiej wspólny język programowania co najmniej (oprócz zajęć) 2 wspólne terminy spotkań całego zespołu (2 godz; 15 minut) tygodniowo w zespole powinien być koordynator/szef; w pełni „demokratyczny” zespół nie sprawdza się

8 ETO – zasady (4) Przy kolejnych zadaniach jest określone, które elementy muszą być uwzględnione. Na przykład: Podano ostateczny termin oddania rozwiązania; tzn. zadanie oddane 1 minutę po terminie uważa się za nie oddane. Musi jednak być zrobione, gdyż kolejne zadania są rozwinięciem poprzedniego.

9 ETO - strona Strona zajęć cvs.ii.uni.wroc.pl/eto2008 Zapoznać się z zasadami korzystania na cvs.ii.uni.wroc.pl Osoby, które decydują się uczęszczać na ETO, powinny się zarejestrować.

10 ETO - ankieta Na stronie Joel Spolsky’ego http://www.joelonsoftware.com jest odnośnik do polskiej wersji tej strony; Na „polskiej stronie” jest przetłumaczony przez A. Koconia artykuł „Partyzancki_poradnik_rekrutacji.htm” Stamtąd są 2 pytania w ankiecie

11 Efektywne tworzenie oprogramowania Przy tworzeniu oprogramowania są ważne: infrastruktura procesy techniki J. R. Richardson, W. A. Gwaltney Jr., Sprzedaj swój program (Ship it) http://www.cafepress.com

12 Infrastruktura Infrastruktura obejmuje: –kontrole wersji –kompilację i konsolidację za pomocą skryptów (ciągłą) –pisanie i wykonywanie testów –śledzenie nowych funkcji –śledzenie błędów Od pierwszego dnia stosuj skrypty kompilacji i konsolidacji Make, Ant, NAnt, Rake Maven 2

13 Narzędzia i infrastruktura (1) programowanie „w piaskownicy” (por. DokuWiki) udostępnianie programów przez repozytorium komputer programisty …

14 Narzędzia i infrastruktura (2) Zarządzanie zasobami pilnujemy każdej wersji każdego pliku od samego początku projektu system zarządzania kodem źródłowym (system kontroli wersji, np. subversion) jeśli czegoś potrzebujesz, to zapisz w repozytorium (nie oszczędzaj miejsca na dysku) http://subversion.tigris.com http://msdn.microsoft.com/vstudio/previous/ssafe (MS Visual SourceSafe)

15 Narzędzia i infrastruktura (3) Początek pracy z SCM (Source Code Management) zapoznaj się z kilkoma systemami (np. Subversion, MS Visual Source Safe) naucz się korzystać przygotuj 1 stronę przewodnika, jak wykonać podstawowe czynności pokaż zespołowi (repozytorium, obszar roboczy, klient, serwer, odgałęzienie, znacznik, łączenie, blokowanie)

16 Narzędzia i infrastruktura (4) Skrypty kompilacji i konsolidacji Tworzymy listę kroków ręcznie prowadzonej kompilacji i konsolidacji Stopniowo zapisuj każdy krok w formie skryptu Automatyczna kompilacja i konsolidacja odbywa się bez udziału użytkownika Systemy ciągłej integracji: CruiseControl http://cruiseconrol.sourceforge.nethttp://cruiseconrol.sourceforge.net CruiseControl.NET sourceforge.net/projects/ccnet www.urbancode.com/projects/anthill maven.apache.org/continuum

17 Śledzenie problemów (1) Regresja błędów – problem (błąd), który poprawiono powraca do kodu Opracuj test dla każdego błędu, który został poprawiony – zapobiegniesz regresji błędu Analizuj wyniki systemu kompilacji i konsoli. (wykorzystaj opcje wysyłania e-mail) Bugzilla http://www.bugzilla.orghttp://www.bugzilla.org FogBugz http://www.fogcreek.com/FogBugz

18 Śledzenie problemów (2) Twórz listę problemów (np. w bazie danych) W jakiej wersji powstał błąd Kto go zgłosił? Czy to poważny błąd? Czy błąd można odtworzyć? W jakim środowisku wykryto błąd? W której wersji wystąpił po raz pierwszy? Kto poprawił błąd? Kto sprawdził poprawkę?

19 Nowe funkcje Dodawaj nowe funkcje zgodnie z ich priorytetem Unikaj przerostu funkcjonalnego – funkcje muszą być na liście zadań i mieć określony priorytet

20 Testowanie Automatyzacja testów – XUnit Testowanie sterowane błędami Testowanie dymowe (w systemach ciągłej integracji) Testy imitujące klienta