Procesy wytwórcze oprogramowania

 Agenda

• Budowa Aplikacji
• Procesy wytwórczy oprogramowania
• Model Kaskadowy
• Agile Manifesto
• Scrum

Rodzaje Aplikacji a Strona WWW
Strona WWW – ma charakter informacyjny, interakcja z nią polega na czytaniu i oglądaniu zamieszczonych na niej treści natomiast nie jest możliwe wykonywanie na niej żadnych czynności. Można rozpatrywać ją jako odpowiednik gazety bądź ulotki.
Aplikacja webowa – ma charakter interaktywny i dostarcza określoną funkcjonalność. Pozwala na przesył danych i otrzymanie informacji zwrotnej a dostęp do niej odbywa się poprzez wpisanie jej adresu w przeglądarkę internetową. Przykładami takich aplikacji mogą być aplikacje bookingowe. Konkursowe, e-learningowe (platforma Future Collars), sprzedażowe, ogłoszeniowe, transakcyjne. CRM, ERP i HR.
Aplikacja desktopowa – aplikacja zainstalowana lokalnie na dysku komputera.

Budowa Aplikacji

BACK-END
·       Wszystko, czego nie widzi użytkownik, a jest konieczne, by aplikacja poprawnie działała
·       Back-endem nazywamy wszystko, co znajduje się bezpośrednio na serwerze
·       Dobrym przykładem może być Baza Danych
·       Następuje tutaj przetwarzanie, zapis oraz odczyt danych z bazy danych
·       Zarządza działaniem aplikacji
·       Po odpowiednim przetworzeniu przekierowuje dane na Front-end przy pomocy API

API
·       Application Programming Interface – Interfejs Programowania Aplikacji
·       Elementy API:
1.     Procedury – odnoszą się do zadań lub funkcji wykonywanych przez program. API dostarczane przez linie lotnicze z danymi o lotach i ich dostępności do stron zajmujących się dystrybucją biletów
2.     Protokoły – format, jaki jest używany do wymiany danych pomiędzy aplikacjami
3.     Narzędzia – można tworzyć z nich nowe programy
·       Sposób w jaki aplikacje łączą się bądź porozumiewają między sobą
·       Służy jako pośrednik między aplikacjami
·       Wszystkie żądania jakie wyślemy do serwera będą przekazane przez API. Przykładowo chcemy wiedzieć czy możemy lecieć z Warszawy do Valetty w określonym dniu.
·       Bez API nie byłoby możliwości dostępu do tak wielu źródeł danych w czasie rzeczywistym
·       Dzięki takiemu współdzieleniu informacji przedsiębiorstwa mogą optymalizować swoje procesy i maksymalizować zyski

FRONT-END
·       Jest to widoczna dla użytkownika część strony
·       Składa się na niego cały wygląd strony: menu, grafiki, animacje, układ tekstu, interfejs
·       Dane pobierane są z back-endu przy pomocy API

Rozważmy przykład:
Strona oferująca bilety lotnicze od wielu przewoźników. Gdy wchodzimy na jej stronę główną mamy do czynienia z front-endem – widzimy pola z możliwością wyboru miejsc odlotu I przylotu, dat, ilości osób. Gdy wybierzemy przycisk szukaj – w tym momencie aplikacja webowa, jaką jest ten serwis – przeszukuje oferty różnych przewoźników przy użyciu API, które zostało przez nich udostępnione. Po wyszukaniu pojawiają się wyniki wyszukiwania – dostajemy kilka ofert na lot od różnych przewoźników o różnych godzinach w wybranych terminach. Jeśli zakładamy konto na takiej stronie lub zapiszesz się do newslettera – twoje dane zostaną zapisane w Bazie Danych znajdujących się na back-endzie tej aplikacji.

MODELE WYTWARZANIA OPROGRAMOWANIA

Model Kaskadowy

 

 
Klasyczny cykl wytwarzania oprogramowania – Waterfall – cechuje go podejście linearne. Polega na wykonywaniu podstawowych czynności cyklu jako odrębnych faz projektowych kolejno po sobie. Każda czynność to tzw. Schodek lub kaskada.

Czynności w modelu kaskadowym:
1.     Planowanie systemu – określenie specyfikacji wymagań
2.     Analiza systemu – analiza wymagań i studium wykonalności
3.     Projekt systemu – projektowanie architektury
4.     Implementacja – tworzenie kodu
5.     Testowanie – następuje testowanie poszczególnych elementów systemu oraz elementów połączonych w całość
6.     Wdrożenie i pielęgnacja powstałego systemu.

Charakterystyczne dla modelu kaskadowego jest sytuacja, w której w jednej z faz wytworzony niesatysfakcjonujący produkt – cofamy się wykonując kolejne iteracje aż do osiągnięcia wymaganego poziomu jakości gotowego do wdrożenia u klienta.

Zalety:
·       Łatwiejszy w prowadzeniu dzięki formalizacji i większej sekwencyjności – długie i uporządkowane procesy sprzyjają zarządzaniu zespołem każdej wielkości
·       Dzięki budżetowaniu i finansowaniu projektu na określony czas pozwala to na efektywniejsze zarządzanie ryzykiem
Wady:
·       Nieelastyczny podział na kolejne rozłączne fazy wytwarzania oprogramowania
·       Przejście do następnej fazy uwarunkowane są zakończeniem poprzedniej
·       Bardzo wysoki koszt i czasochłonność iteracji poprzez powtarzanie wielu czynności
·       Długi czas trwania projektu od określenia wymagań do momentu wydania do klienta – wytworzony produkt może już nie spełniać wymagań klienta
·       Czas trwania projektu zależy od zakończenia poszczególnych faz
·       Z punktu widzenia testera: dużo defektów wykrywanych jest w późniejszych fazach projektu
·       Zmiany w produkcie mogą być niemożliwe ze względu na wcześniej określone wymagania
Dla Kogo?
·       Mniej doświadczone zespoły
·       Zespoły potrzebujące harmonogramu, który jest sekwencyjny i przewidywalny
·       W przedsiębiorstwach o niskiej tolerancji na zmianę lub ryzyko
·       W projektach, gdzie klient ma ograniczone zasoby i/lub czas, przez co ograniczona jest możliwość interakcji w trakcie trwania projektu
·       Proste projekty o niewielkich wymaganiach
·       Projekty długoterminowe

Manifest Agile

W 2001 roku został opublikowany Agile Manifesto – jest to manifest programowania zwinnego.

Założeniami Agile są:

Ludzie i interakcje ponad procesy i narzędzia

Działające oprogramowanie ponad szczegółową informację

Współpracę z klientem ponad negocjację kontraktów

Odpowiedź na zmianę ponad trzymanie się określonego planu

Model Zwinny – jest to podejście iteracyjne do zarządzania projektami i tworzenia oprogramowania, które wspomaga zespoły w zapewnieniu wartości dla klientów. Zespół dostarcza pracę w małych partiach, a wymagania są oceniane w sposób ciągły i dostosowywane w razie nowych potrzeb, dzięki czemu zespoły agile mogą szybko reagować na zmiany zachodzące w otoczeniu.

Zasady Agile
·       Najwyższy priorytet ma zadowolenie klienta
·       Gotowość do zmian w każdym, nawet późnym etapie projektu
·       Możliwość zmian zapewniająca klientowi konkurencyjność
·       Dostarczanie oprogramowania często
·       Bliska współpraca między biznesem i zespołem developerskim
·       Działające oprogramowanie jest podstawową miarą postępu
·       Najlepsze rozwiązania architektoniczne pochodzą od zespołów samoorganizujących się
·       W regularnych odstępach zespół dokonuje analizy swoich możliwości

Frameworki Agile
·       Scrum
·       Kanban
·       Lean
·       XP Extreme Programming
 
Scrum i Extreme Programming jest najczęściej wybierany przez zespoły programistyczne.
Kanban najczęściej znajduje zastosowanie w zespołach zorientowanych na usługi.
Lean odnosi się do koncepcji zarządzania przedsiębiorstwem.

Scrum

Scrum nie wyznacza sposobu postępowania aby osiągnąć cel – wyznacza sposób współpracy i określa wydarzenia jakie muszą wystąpić, natomiast nie narzuca, jak ma zostać wykonany produkt.

FILARY:
•       Przejrzystość – wszystkie aspekty pracy są widoczne dla wszystkich, dostępne i zrozumiane w ten sam sposób, przykładem może być Definition of Done
•       Inspekcja – artefakty scrumowe (Backlog) oraz postępy realizacji prac są regularnie poddawane kontroli w celu oceny i wykrycia ewentualnych odchyleń od oczekiwanych rezultatów
•       Adaptacja – w momencie, gdy proces inspekcji wykryje rozbieżność w stosunku do oczekiwanych rezultatów – następuje korekta

Sercem Scruma jest SPRINT – ograniczony maksymalnie do jednego miesiąca czas (zwyczajowo dwa tygodnie), podczas którego produkt jest wytwarzany, „ukończony” i gotowy do użycia i potencjalnego wydania przyrostu (wytworzonej przez 2 tygodnie „porcji” oprogramowania). Nowy sprint zaczyna się po ukończeniu kolejnego.

Role w Scrumie:
•       Interesariusze – szeroko pojęte otoczenie – klienci dostarczający oczekiwania i wymagania do projektu*
•       Product Owner – interesariusz, który jest odpowiedzialny za rozwój produktu. Tworzy wizję i zarządza budżetem. Powinien być osobą decyzyjną, posiadać wiedzę z obszaru biznesu, produktu oraz na temat użytkowników końcowych.
•       Deweloperzy – ideą Scrum jest dobry przepływ informacji, dlatego zespół nie może być zbyt duży – 3-9 osób. Wszyscy członkowie bez względu na specjalizację nazywani są deweloperami. Z założenia jest to zespół samoorganizujący się ze wszystkimi umiejętnościami koniecznymi do wykonania produktu. Zespół bierze odpowiedzialność za wytworzenie produktu pracy i w momencie nieobecności któregoś z członków zespołu – reszta wykonuje jego obowiązki by nie obniżać jakości pracy i produktu. Wartości jakie powinien wyznawać zespół Scrum: Zaangażowanie, Otwartość, Odwaga, Skupienie, Szacunek
•       Scrum Master – służalczy kierownik – powinien być doświadczony w Scrum, jest mistrzem ceremonii – moderuje spotkania i procesy, usuwa przeszkody, dba o komfort pracy w zespole. Zarządza procesem, nie zespołem.

Scrum Team = Product Owner + Deweloperzy + Scrum Master

*Interesariusze nie są oficjalną rolą w SCRUM

 
Artefakty
•       Product Backlog – jest to uporządkowana lista zadań w projekcie – na szczycie tej listy znajdują się zadania o najwyższym priorytecie. Lista ta ma charakter otwarty – nie jest ona stała przez cały czas trwania projektu.
•       Sprint Backlog – lista zadań wyodrębnionych do sprintu.
•       Inkrement – ukończone zadania ze sprintu zgodnie z definicją Definition of Done. Jest to gotowy fragment oprogramowania niezależnie o decyzji o wydaniu do klienta.

Wydarzenia
• Sprint – ograniczenie czasowe – iteracja – podczas której zespół wykonuje pracę by przekształcić pomysł w produkt – inkrement – potencjalnie gotowy do wydania klientowi.
• Planowanie Sprintu – Planowanie pracy na kolejny sprint we współpracy ze wszystkimi członkami zespołu. Następuje określenie celu sprintu.
•       Sprint Daily – codziennie krótkie spotkanie (15 minut) zespołu w celu przedyskutowania aktualnych zadań, problemów i naszych planów na kolejny dzień.
•       Refinement Sprintu *– spotkanie mające na celu uporządkowanie backlogu by odzwierciedlał aktualne wymagania, ale także doprecyzowanie szczegółów zadań w backlogu. Nie jest to oficjalne wydarzenie w SCRUM.
•       Review Sprintu – spotkanie zespołu i interesariuszy w celu zapoznania się z produktem sprintu, inspekcji inkrementu oraz ostatecznej oceny.
•       Retrospektywa – spotkanie mające na celu inspekcję sprintu, zespołu i opracowania usprawnień, które korzystnie wpłyną na rozwój zespołu i projektu.


Cykl życia oprogramowania – Model Zwinny






Proces wytwórczy