Efektywne tworzenie oprogramowania

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