INŻYNIERIA OPROGRAMOWANIA LAB 1 MODELE TWORZENIA OPROGRAMOWANIA dr inż. Joanna Świebocka-Więk
O mnie Kogo szukać? dr inż. Joanna Świebocka-Więk Gdzie szukać: Pokój 216, budynek D10 Zespół Technik Informacyjnych i Biometrii Katedra Informatyki Stosowanej i Fizyki Komputerowej Kiedy szukać? Konsultacje: czwartek 10:20-14:40 (lub inny obopólnie ustalony termin) Gdzie pisać: E-mail: jsw@agh.edu.pl E-mail do przesyłania sprawozdań i projektów: jswprojekty@gmail.com
Czego od Państwa oczekuje? Podziału na zespoły liczące 6-7 osób które w przeciągu semestru wykonają 1 wspólny projekt (80 pkt) Wykonania przez każdego z osobna krótkiej prezentacji na wybrany z listy temat. Lista pojawi się w trakcie semestru. Obecności na każdych zajęciach Systematycznej pracy, która może być weryfikowana np. w postaci krótkiego kolokwium z tematyki poprzednich zajęć
Kim będę w zespole? 1. Kierownik projektu (Team Leader) 2. Inżynier systemowy (może być kilku) 3. Programista (może być kilku) 4. Tester (może być kilku) 5. Inne (po zatwierdzeniu przez Prowadzącego)
Tematyka zajęć 1. Modele tworzenia oprogramowania. 2. Tworzenie harmonogramu pracy 3. Analiza i specyfikacja wymagań 4. Diagramy UML: Część I 5. Diagramy UML: Część II 6. Diagramy UML: Część III 7. Konsultacje i podsumowanie dotychczasowej pracy 8. Implementacja kodu 9. Testy jednostkowe 10.Testy integracyjne. Walidacja a weryfikacja. 11.Testy akceptacyjne i systemowe. Pielęgnacja i konserwacja oprogramowania. 12.Prezentacje studentów: Kierownicy projektu i inżynierowie systemowi. 13.Prezentacje studentów: Programiści. 14.Prezentacje studentów: Testerzy.
INŻYNIERIA OPROGRAMOWANIA TO METODOLOGIA TWORZENIA, OPTYMALIZACJI I DOKUMENTOWANIA OPROGRAMOWANIA
Po co jest Inżynieria Oprogramowania Ryzyko budowy domu a ryzyko projektu informatycznego. Jakie mamy w tym względzie doświadczenie (luka poznawcza)? Kryzys informatyczny w USA i badania Standish Group: obecnie 175 tys. projektów informatycznych/rok (250 mld $), 31% jest przerywanych na etapie pośrednim 52% projektów przekracza pierwotny budżet (typowy system jest droższy od założeń o 89%!) zaledwie 16% projektów kończonych jest terminowo, bez przekraczania budżetu i zmniejszania funkcjonalności
Fakt 60 % funkcjonalności oprogramowania używanych jest rzadko albo wcale
Po co jest Inżynieria Oprogramowania Określenie i charakterystyka podstawowych etapów tworzenia i funkcjonowania oprogramowania Wybór modelu, gwarantującego OPTYMALNY przebieg tych etapów Tworzenie dokumentacji projektów Podstawowe czynności związane z tworzeniem oprogramowania: Określanie wymagań i specyfikacji Projektowanie Implementacja Testowanie - walidacja i weryfikacja Wdrożenie Eksploatacja i konserwacja (pielęgnacja)
1. Inicjalizacja systemu, wstępne planowanie: Określenie obszaru zastosowania systemu informatycznego (wspomaganie, zastąpienie dotychczasowego systemu), studium wykonalności 2. Określenie wymagań, ich analiza i specyfikacja Jakie zagadnienia system ma rozwiązywać? Określenie właściwości systemu, jego wydajności, zasobów sprzętowych, oczekiwań Klienta, niezbędnych do eksploatacji systemu 3. Specyfikacja funkcjonalna (systemowa). Zdefiniowanie obiektów składowych, ich atrybutów i rodzajów przekształceń 4. Dekompozycja problemu. W oparciu o specyfikację i wymagania system dzielony jest na podsystemy (komponenty). Analiza pod kątem zastosowania istniejących rozwiązań informatycznych (samodzielne wykonanie a zakup technologii) 5. Architektura projektu, specyfikacja konfiguracji Zdefiniowanie zależności między komponentami i modułami, z uwzględnieniem ich budowy i specyfikacji wymagań 6. Projektowanie szczegółowe, specyfikacja komponentów Opracowanie metod przetwarzania danych w poszczególnych komponentach 7. Implementacja komponentów i testy jednostkowe Etap tworzenia kodu źródłowego komponentów, testowanie ich podstawowych funkcji 8. Integracja systemu, testy integracyjne i systemowe Sprawdzenie kompletności i zgodności ze specyfikacją komponentów, weryfikacja wydajności 9. Dokumentacja projektu. Opracowanie i uporządkowanie dokumentacji (powstałej w trakcie tworzenia projektu) i dostarczenie systemu 10. Instalacja systemu (procedury instalacyjne, dokumentacja instalacyjna) 11. Szkolenia dla użytkowników (możliwości i ograniczenia systemu) 12. Eksploatacja i konserwacja systemu (testy akceptacyjne usuwanie błędów dostrzeżonych w trakcie użytkowania, rozbudowa systemu, poprawa wydajności)
Nakład pracy przy tworzeniu oprogramowania [%] 7 6 5 15 67 Ekploatacja Testowanie Kodowanie Specyfkacja potrzeb Projektowanie
Źródła błędów w cyklu tworzenia oprogramowania [%] 10 7 27 56 analiza potrzeb projektowanie inne kodowanie
Koszt naprawy błędów [%] 13 1 4 82 analiza potrzeb projektowanie inne kodowanie
Waterfall Wierzę w ten koncept, ale implementacja opisana powyżej jest ryzykowana i naraża się na porażkę. Dr. Winstone W. Royce, Preceedings, IEE WESCON, sierpień 1970
Waterfall Czytelny i przejrzysty, ale niepraktyczny w realizacji Dopóki wszystko nie będzie gotowe, nic nie jest gotowe Konstrukcja i testowanie odbywa się na podstawie NIEZMIENNYCH WYMAGAŃ Poszczególne etapy wykonuje się TYLKO RAZ (każda iteracja znacząco zwiększa koszty całego projektu) poprawność funkcjonalna pojedynczego modułu nie oznacza, iż będzie on współdziałał poprawnie z resztą modułów. Testowanie odbywa się pod koniec projektu
Waterfall - cechy proces fazowy, sekwencyjny; ¼ czasu spędzona na planowaniu; na początku nad projektem pracują eksperci, a następnie szeregowi deweloperzy; z góry przewidziany rezultat końcowy; projekt odnosi sukces, gdy: wszystkie wymagania zostaną zaspokojone, zakończy się w przewidzianym terminie, budżet nie zostanie przekroczony, otrzymany zostanie produkt o ustalonej wcześniej jakości.
Waterfall możliwe problemy niejasne wymagania; rosnący koszt wprowadzania zmian; zawiedzione oczekiwania klientów; brak czasu na testowanie; postęp pracy trudny do określenia w danym momencie; brak możliwości ciągłego zapewnienia jakości; późna integracja modułów oznaczająca późne pojawianie się błędów.
Waterfall-statystyka 52% wymagań zostało zaimplementowanych; 64% powstałych funkcjonalności jest używane rzadko; 34% projektów zakończone sukcesem.
Waterfall kiedy to ma sens? zakres projektu i wymagania się nie zmieniają; zespół doskonale zna technologię; zespół dobrze rozumie wymagania; zespół dobrze oszacował zakres prac do wykonania; nic nie wpłynie na zmianę planu.
Widoczność postępu pracy w tradycyjnym projekcie.
Model V precyzyjnie pokazuje zależności, jakie powinny łączyć kolejne etapy projektu. Każdy etap projektowania kończy się stworzeniem danych wejściowych dla następnej fazy oraz do korespondującej z nim fazy weryfikacji. zachęca do jak najwcześniejszego rozpoczęcia procesu tworzenia planów testów, specyfikacji testowej i samego testowania. dzięki analizie grafu możemy łatwo zidentyfikować obszary, gdzie stworzona dokumentacja powinna być sprawdzona.
Model spiralny
Model spiralny wersja win-win
Agile manifest (2001) Poprzez wytwarzanie oprogramowania oraz pomaganie innym w tym zakresie odkrywamy lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń zaczęliśmy przedkładać: Ludzi i ich interakcje nad procedury i narzędzia. Działające oprogramowanie nad wyczerpującą dokumentację. Współpracę z klientem nad negocjację umów. Reagowanie na zmiany nad realizowanie planu. Chociaż doceniamy elementy wymienione po prawej stronie, to jednak bardziej cenimy pozycje po lewej. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
12 zasad (Principles behind the Agile Manifesto) 1. Naszym najwyższym priorytetem jest zadowolenie klienta osiągane przez wczesne i ciągłe dostarczanie wartościowego oprogramowania. 2. Zmiany w wymaganiach są mile widziane nawet na późnych etapach projektu. Proces Agile wykorzystuje zmianę do osiągnięcia przewagi we współzawodnictwie na korzyść klienta. 3. Dostarczaj oprogramowanie często, w odstępach czasu od kilku tygodni do kilku miesięcy, preferując mniejsze odstępy czasowe. 4. Ludzie biznesu i deweloperzy muszą pracować razem codziennie przez cały czas trwania projektu. 5. Projekty powierzaj zmotywowanym jednostkom. Daj im środowisko i wsparcie, którego potrzebują i zaufaj im, że praca zostanie wykonana. 6. Najskuteczniejszą i najwydajniejszą metodą przekazywania informacji w zespole deweloperów jest rozmowa w cztery oczy. 7. Działające oprogramowanie jest podstawową miarą postępu. 8. Procesy Agile promują zrównoważony rozwój. Sponsorzy, deweloperzy i użytkownicy powinni być w stanie utrzymać stałe tempo. 9. Ciągła koncentracja na technicznej doskonałości i dobrym projekcie poprawia zwinność 10. Prostota sztuka zwiększania ilości pracy niewykonanej jest niezbędna. 11. Najlepsze architektury, wymagania i projekty wyłaniają się z samoorganizujących się zespołów. 12. W regularnych odstępach czasu zespół zastanawia się, jak zwiększyć wydajność, a następnie odpowiednio dopasowuje swoje zachowanie.
Metodyki zwinne Metodyka Crystal (Crystal family), Projektowanie zorientowane na właściwości (Feature Driven Development), Modelowanie zwinne (Agile Modeling), Programowanie ekstremalne (Extreme Programming), Adaptacyjny rozwój oprogramowania (Adaptive Software Development), Metodyka scrum (Scrum development), Prototypowanie (Prototyping methodology), Szybkie programowanie internetowe (Internet Speed Development), Pragmatyczne programowanie (Pragmatic Programming).
Ale czy Agile jest dla Ciebie? 1. Przystosowanie do zmian 2. Krótki cykle/częste dostarczanie 3. Prosty projekt 4. Programowanie w parach 5. Refaktoryzacja 6. Retrospektywa 7. Wiedza ukryta 8. Rozwój sterowany testami 9. Dobry kontakt z Klientem 10. Wykwalifikowany zespół który się doskonali
Zadanie domowe Podzielić się na zespoły projektowe. Podział winien być poparty listą nazwisk wraz z przyporządkowanymi funkcjami w zespole. Wybór metodyki tworzenia oprogramowania W przeciągu 4 dni roboczych należy dostarczyć wizję 5 projektów, wraz z opisem na około połowę strony A4. Spośród zgłoszonych tematów Prowadzący wybierze 1 temat do realizacji. W przypadku przekroczenia terminu, Prowadzący zleci wykonanie projektu na zadany przez siebie temat.
V. Satir
Projektant wie, że osiągnął doskonałość, nie wtedy, kiedy nie można nic dodać, ale wtedy, kiedy nie można nic ująć. Antoine De Saint-Exupery