Efektywne tworzenie oprogramowania 2008/2009

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

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

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”

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

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)

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ę

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.

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ć.

ETO - ankieta Na stronie Joel Spolsky’ego 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

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)

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

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

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) (MS Visual SourceSafe)

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)

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 CruiseControl.NET sourceforge.net/projects/ccnet maven.apache.org/continuum

Ś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 ) Bugzilla FogBugz

Ś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ę?

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

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