Efektywne tworzenie oprogramowania

2008/2009

Forty Years of Software Engineering

• Konferencja w Garmisch – 1968

• 50 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”

http://icse08.upb.de/program/downloads.html

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ły40% 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

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

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

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)

http://subversion.tigris.com

http://msdn.microsoft.com/vstudio/previous/ssafe

(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 http://cruiseconrol.sourceforge.net

CruiseControl.NET sourceforge.net/projects/ccnet

www.urbancode.com/projects/anthill 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 e-mail) Bugzilla http://www.bugzilla.org

FogBugz http://www.fogcreek.com/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