Modele implementacji oprogramowania. Michał Tomal

Save this PDF as:
 WORD  PNG  TXT  JPG

Wielkość: px
Rozpocząć pokaz od strony:

Download "Modele implementacji oprogramowania. Michał Tomal"

Transkrypt

1 Modele implementacji oprogramowania Michał Tomal

2 Proces wytwórczy oprogramowania (Software development process) lub Cykl życia oprogramowania (Software development lifecycle) Jest to struktura określająca sposób wytwarzania/rozwoju oprogramowania. Istnieje wiele modeli takich procesów, opisujących różne podejścia do rozmaitych zadań i działań, które zachodzą podczas wytwarzania oprogramowania. Istnieje także podejście, które proces wytwórczy od cyklu życia, uznając, że cykl jest bardziej pojęciem bardziej ogólnym, natomiast proces bardziej szczegółowym. Np. niektóre procesy wytwórcze pasują do spiralnego modelu cyklu życia oprogramowania.

3 ISO To międzynarodowy standard do opisywania metod wyboru, implementacji i kontroli cyklu życia oprogramowania. Opisuje on 23 procesy, 95 czynności (activities), 325 zadań (tasks) oraz 224 wyników (outcomes) powiązanych z procesami. Nowsza wersja ISO 12207:2008 definiuje 43 procesy. 5 podstawowych procesów Zbieranie informacji (Acquisition) Dostarczanie (Supply) Tworzenie (Development) Wdrażanie (Operation) Wpieranie (Maintenance)

4 Modele procesów wytwórczych oprogramowania 1. Model kaskadowy (Waterfall) 2. Model spiralny (Spiral) 3. Model przyrostowy (Iterative and Incremental) 4. RUP (Rational Unified Process) 5. Programowanie zwinne (Agile)

5 Model kaskadowy (Waterfall) Wprowadzony w 1970 roku w artykule Managing the Development of Large Software Systems autorstwa Winstona W. Royca. Polega on na sekwencyjnym wykonywaniu podstawowych czynności, będącymi kolejnymi fazami projektu. Każda z faz musi być dokładnie udokumentowana i ukończona przed przejściem do następnej.sd 1. Specyfikacja wymagań 2. Projektowanie 3. Implementacja 4. Integrowanie 5. Testowanie 6. Instalacja 7. Konserwacja

6 Specyfikacja wymagań Projektowanie Implementacja Integrowanie Testowanie Instalacja Konserwacja

7 Zalety Wady Każda faza ukończona bezbłędnie i w 100% minimalizuje ryzyko porażki i błędów Pełna i dokładna dokumentacja sprawia, że w przypadku odejścia pracowników wiedza nie jest tracona Proste i zdyscyplinowane podejście, łatwe do zrozumienia i wyjaśnienia Pozwala w łatwy sposób określić kamienie milowe Trudny do zastosowania w praktyce zwłaszcza dla złożonych projektów, w których klienci mogą nie umieć precyzyjnie sformułować wymagań Projektanci mogą nie przewidzieć przyszłych problemów implementacji we wczesnych fazach Każdy błąd we wcześniejszych fazach może spowodować kosztowne powroty poprzednich faz Nadaje się tylko do stabilnych projektów, w których projektanci mogą przewidzieć zakresy problemów i stworzyć poprawny projekt przed rozpoczęciem implementacji Nieelastyczny podział na fazy Duże koszty i czasochłonność podczas powtarzania poszczególnej fazy

8 Model spiralny (Spiral) Zdefiniowany przez Barry ego Boehm a w 1989 roku w artykule A Spiral Model of Software Development and Enhancement Model ten łączy cechy modelu kaskadowego oraz prototypowego. Proces ten ma postać spirali, w której każda pętla przedstawia kolejne fazy procesu. Każda faza składa się z czterech etapów. 1. Ustalenie celów 2. Rozpoznanie i redukcja zagrożeń 3. Tworzenie i testowanie 4. Planowanie następnej iteracji.

9 Narastanie kosztów 1. Ustalenie celów 2. Rozpoznanie i redukcja zagrożeń Plan wymagań Prototyp 1 Prototyp 2 Prototyp 3 Prototyp 4 Koncepcja działań Koncepcja wymagań Wymagania Koncepcja ogólna Koncepcja szczegółowa Plan tworzenia Weryfikacja i walidacja Implementacja Plan testowania i integracji Weryfikacja i walidacja Integracja Testowanie 4. Planowanie następnej iteracji Oddanie 3. Tworzenie i testowanie

10 Zalety Wady Duży nacisk na rozpoznawanie i eliminowanie zagrożeń, skutkujący wysoką niezawodnością i szansą realizacji projektu Bodowa prototypów pozwala na lepszą ocenę zgodności i weryfikacji wymagań Nadaje się do dużych projektów Pozwala szybko reagować na zmieniające się czynniki i wymagania Software jest wytwarzany już we wczesnych etapach Wymaga bardzo dobrze wyszkolonych i doświadczonych ekspertów do analizy ryzyka, planowania, relacji z klientem itd. Iteracyjność powoduje, że model jest kosztowny i czasochłonny Sukces projektu zależy w znacznej mierze od analizy ryzyka (poważne konsekwencje błędów) Nie nadaje się do małych projektów Złożoność, ciężki do ścisłego przestrzegania

11 Model przyrostowy (Iterative and incremental) Został zdefiniowany w celu wyeliminowania wad modelu wodospadowego. Stosowany do tworzenia początkowo małych, ale z czasem rozrastających się części oprogramowania. Pozwala na osiąganie celów projektowych klientów, którzy nie potrafią dokładnie określić własnych potrzeb. W modelu tym funkcjonalność systemu jest dzielona na porcje. W każdej z iteracji część funkcjonalności jest dostarczana poprzez pracę w różnych dziedzinach (wymagania, implementacja, testy itd.). Takie działanie jest dzielona na fazy: 1. Rozpoczęcie (Inception) 2. Opracowanie (Elaboration) 3. Konstrukcja (Constuction) 4. Przekazania (Transition) Każda z faz może zostać podzielona na kilka iteracji, które są określone ramami czasowymi, a nie funkcjonalnymi.

12 Modelowanie biznesowe Wymagania Analiza i projekt Implementacja Testowanie Wdrażanie Czas

13 Zalety Wady Częsty kontakt z klientem Nie trzeba od razu definiować pełnych wymagań Wczesne dostarczenie klientowi pierwszych wersji/fragmentów oprogramowania Opóźnienia dotyczące tylko pewnych fragmentów nie mają wpływu na czas ukończenia całego projektu Możliwość korzystania z doświadczeń wyniesionego podczas tworzenia i użytkowania wcześniejszych części/wersji systemu Pozwala na wczesne wykrywanie problemów lub złych założeń, zanim spowodują poważne straty Wzrost kosztów związanych z uniezależnieniem realizacji fragmentów systemu Trudne wyodrębnianie niezależnych funkcjonalności Dodatkowy nakład pracy związany z koniecznością implementacji interface ów aby zapewnić zgodność z docelowym systemem

14 RUP (Rational Unified Process) To iteracyjny struktura procesu wytwórczego oprogramowania stworzona przez Rational Software Corporation, część IMB od Nie jest to pojedynczy proces, a raczej szablon procesu. Zamierzeniem twórców było, aby organizacje developerskie i zespoły projektowe same dostosowywały go do własnych potrzeb. Zawiera on hipertekstową bazę wiedzy z przykładowymi artefaktami i szczegółowymi opisami różnych typów czynności. Bazuje on na sześciu podstawowych najlepszych praktykach 1. Iteracyjne wytwarzanie oprogramowania z ryzykiem będącym podstawą kierowania iteracjami (Iterative Development) 2. Zarządzanie wymaganiami (Requirements Management) 3. Korzystanie z architektury opartej na komponentach (Component-based architecture) 4. Graficzne projektowanie oprogramowania (Model software visuality) 5. Ciągłej kontroli jakości (Quality Assurance) 6. Kontroli zmian (Change Management)

15 Cykl życia RUP oparty jest na przyrostowym modelu cyklu życia oprogramowania, więc tak samo wyróżnia się cztery fazy: 1. Rozpoczęcie (Inception) 2. Opracowanie (Elaboration) 3. Konstrukcja (Constuction) 4. Przekazania (Transition) Konstrukcja RUP bazuje na klockach (building blocks lub content elements) opisujących co ma być stworzone, jakie umiejętności są wymagane oraz jak krokpo-kroku jak trzeba osiągać poszczególne cele. Głównymi klockami są; 1. Role (kto) definiuje zestaw wymaganych umiejętności, kompetencji i odpowiedzialności 2. Produkty (co) reprezentuje wyniki zadań wraz z wszelkimi dokumentami i modelami stworzonymi podczas działania procesu 3. Zadania (jak) - opisuje jednostkę pracy przypisaną roli, dającą znaczący wynik

16 W każdej iteracji otrzymywane są wyniki prac z sześciu dziedzin (dyscyplin) inżynierskich (Engineering Disciplines) oraz trzech dziedzin pomocniczych (Supporting Disciplines): 1. Modelowanie biznesowe (Business Modeling Discipline) 2. Wymagania (Requirements Discipline) 3. Analiza i projektowani (Analysis and Design Discipline) 4. Implementacja (Implementation Discipline) 5. Testowanie (Test Discipline) 6. Wdrażanie (Deployment Discipline) a. Środowisko (Environment discipline) b. Zarządzanie konfiguracją i zmianami (Configuration and Change management discipline) c. Zarządzanie projektem (Project management discipline)

17 Modelowanie biznesowe Wymagania Analiza i projekt Implementacja Testowanie Wdrażanie Czas

18 Open Unified Process (OpenUP) Jest częścią open-source owego szablonu procesów Eclipsa (Ecipse Process Framework) stworzonego przez fundację Eclispe. Jego celem ułatwienie przyswojenia podstaw RUP. Zachował on najważniejsze cechy RUP takie jak: 1. Iteracyjne wytwarzanie oprogramowania 2. Wytwarzanie sterowane przypadkami użycia oraz scenariuszami 3. Zarządzanie ryzykiem 4. Skoncentrowanie na architekturze (architecture-centric approach)

19 OpenUP/Basic Jest najbardziej zwinną i lekką formą OpenUP. Wywodzi się wkładu w open source procesu zwanego Basic Unified Process (BUP) stworzonego przez IBM. Został on zmieniony w Eclipse Foundation w 2005 roku i zmienił nazwę na OpenUP/Basic w Zachował on najważniejsze cechy RUP, podobnie jak OpenUP, dodatkowo odrzucając najbardziej opcjonalne jego elementy, jednocześnie część z nich łącząc. Tym sposobem jest znacznie prostszym procesem, który ciągle jest zgodny z jego zasadami. Nadaje się do małych projektów, których tworzenie zajmuje od 3 do 6 miesięcy tworzenia przez 3 do 6 osób.

20 Manifest Zwinnego Wytwarzania Oprogramowania (Agile Manifesto) To deklaracja wspólnych zasad dla zwinnych metodyk tworzenia oprogramowania. Została opracowana podczas spotkania jakie miało miejsce lutego 2001 roku w ośrodku wypoczynkowym Snowbird w Utah. Uczestniczyli w nim reprezentanci nowych metodyk tworzenia oprogramowania będących alternatywą dla tradycyjnego podejścia opartego na modelu kaskadowym. Na spotkaniu pod manifestem podpisało się 17 osób, a na stronie internetowej jemu poświęconej możliwe jest także podpisanie się pod nim.

21 Treść Manifestu Agile Poprzez wytwarzanie oprogramowania oraz pomaganie innym w tym zakresie odkrywamy lepsze sposoby realizowania tej pracy. W wyniku tych doświadczeo zaczęliśmy przedkładad: Ludzi i ich wzajemne interakcje (współdziałanie) ponad 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. Oznacza to, że wprawdzie doceniamy to co wymieniono po prawej stronie, to jednak bardziej cenimy to co wymieniono po lewej

22 Programowanie zwinne (Agile software development) Opiera się ono przyrostowym (i iteracyjnym) modelu cyklu życia oprogramowania, gdzie wymagania i rozwiązania ewoluują przy współpracy samoorganizujących się zespołów wytwarzających oprogramowanie. Kieruje się następującymi zasadami: 1. Satysfakcja klienta poprzez szybkie dostarczenie użytecznego softwaru 2. Przyjmowanie zmian wymagań, nawet w późnych etapach powstawania 3. Częste dostarczanie działającego oprogramowania (tygodnie nie miesiące) 4. Działające oprogramowanie jest najważniejszą miarą postępu 5. Zrównoważone wytwarzanie, zdolność utrzymania ciągłego tempa 6. Bliska, codzienna współpraca między biznesmenami, a twórcami oprog. 7. Bezpośrednie konwersacje są najlepszą formą komunikacji 8. Projekty budowane wokół zmotywowanych jednostek, godnych zaufania 9. Ciągła uwaga zwracana na aspekty techniczne i dobry projekt 10. Prostota 11. Samoorganizujące się zespoły 12. Regularne przystosowywanie się do zmiennych okoliczności

23 Scrum To metodyka zarządzania projektem wywodząca się od programowania zwinnego. Pomimo, że została stworzona do zarządzania projektami wytwarzania oprogramowania, to może być również wykorzystywana przez zespoły konserwujące oprogramowanie lub jako ogólne podejście do zarządzanie programem/projektem. Pomysł przedstawili Hirotaka Takeuchi i Ikujiro Nonaka w artykule z 1986 zatytułowanym The New New Product Development Game. W 1995 r. Jeff Sutherland i Ken Schwaber zaprezentowali dokument opisujący Scrum podczas warsztatów Business Object Design and Implementation na konferencji OOPSLA w Austin w Teksasie. Nazwa Scrum pochodzi od terminu występującego w grze rugny, tłumaczonego powszechnie jako "młyn" lub "przepychanka"

24 Scrum to szkielet procesu zawierający zestaw praktyk oraz predefiniowane role. Głównymi rolami są: 1. Mistrz (ScrumMaster), który zarządza procesami (zamiast PMa) 2. Właściciel Produktu (Product Owner) reprezentujący klienta,interesariuszy 3. Zespół (Team) grupa około 7 osób, faktycznie zajmująca się analizą, projektowaniem, implementacją, testowaniem, itd.; W pierwszym etapie tworzona jest lista wymagań użytkownika, są one gromadzone w postaci "historyjek, opisujących jedną cechę systemu. Zespół pracuje zwykle w 2-4 tygodniowym przedziale czasowym zwanym sprintem, którego efektem powinien być dostarczenie kolejnego działającego fragmentu produktu. Zestaw funkcjonalności do wykonania w sprincie pochodzi z rejestru produktu (product backlog), który zawiera listę zadań wraz z ich priorytetem. O tym, które z zadań zostanie wyznaczone do kolejnego sprintu, rozstrzygane jest podczas spotkań, na których Właściciel Produktu informuje zespół czego oczekuje. Drużyna następnie ustala ile z tego jest w stanie zrobić podczas kolejnego sprintu i zapisuje to w rejestrze sprintu (sprint backlog). Podczas przebiegu nikt nie ma prawa modyfikować rejestru sprintu, więc wymagania są zamrożone. Wytwarzanie jest ograniczone ramami czasowymi i sprint musi zakończyć się w wyznaczonym terminie. Jeśli jakieś zadanie nie jest zakończone, z jakiegoś powodu, jest pozostawiane i wraca do rejestru produktu. Po zakończeniu drużyna demonstruje, jak korzystać ze stworzonego oprogramowania.

25 Bardzo ważnym aspektem metodyki Scrum jest bliska, codzienna współpraca między poszczególnymi osobami. Stąd konieczność odbywania się następujących spotkań: 1. Codzienny młyn (Daily Scrum) codziennie, podczas sprintu, charakteryzuje się: Zaczyna się punktualnie Każdy może w nim uczestniczyć, jednak zabierać głos może tylko Drużyna i ScrumMaster Spotkanie może trwać tylko 15 min. Powinno się odbywać zawsze w tym samym miejscu i porze dnia Każdy członek zespołu odpowiada na pytania: Co zrobiłeś od wczoraj? Co planujesz zrobić dzisiaj? Czy masz jakieś problemy powstrzymujące Cię przed osiągnięciem celu? 2. Planowanie Sprintu (Sprint Planning Meeting) przed rozpoczęciem każdego sprintu, charakteryzuje się: Wybieranie co ma być zrobione Przygotowanie rejestru sprintu zawierającego czas potrzebny na wykonanie Stwierdzenie ile z roboty jest wykonalne w czasie aktualnego przebiegu Może trwać maksymalnie 8 godz. (jedna połowa na ustalenie priorytetów zadań między Drużyną a Właścicielem, a druga dla Drużyna na przygotowanie rejestru sprintu)

26 3. Inspekcja Sprintu (Sprint Review Meeting) na koniec każdego sprintu Sprawdzenie, czy plan został wykonany Prezentacja ewentualnych rezultatów interesariuszom (Demo) Maksymalnie 4 godz. 4. Spotkanie Retrospektywne (Sprint Retrospective) po skończeniu sprintu Wszyscy członkowie drużyny wymieniają uwagi nt. minionego sprintu Tworzenie ciągłego ulepszanie procesu Zadanie dwóch podstawowych pytań: Co poszło dobrze podczas sprintu?; Co może być poprawione podczas następnego? Maksymalnie 3 godz.

27 Feature Driven Development (FDD) Jest zwinnym procesem wytwarzania oprogramowania, opartym na przyrostowym modelu cyklu życia oprogramowania. Jego głównymi celami jest umożliwienie wytwarzania użytecznego oprogramowania w powtarzalny i efektywny sposób, zapewniając wiarygodne informacje o stanie projektu informatycznego do wszystkich jego uczestników, z minimalnym narzutem na pracę programistyczną. Pierwotnie został on wymyślony przez Jeff a De Luca w 1997 roku, przy okazji tworzenia oprogramowania dla dużego banku w Singapurze. Pierwszy opis FDD ukazał się w 1999 roku w książce Java Modeling in Color with UML Peter a Coad a, Eric a Lefebvre a i Jeff a De Luca. Bardziej ogólny opis umieszczony został w książce A Practical Guide to Feature-Driven Development Steve a Palmera w 2002 roku.

28 Proces FDD bazuje na pięciu podstawowych czynnościach: 1. Budowa ogólnego modelu (Develop Overall Model) Na początku projektu zespół projektowy opracowuje model systemu, zapewniający wspólne rozumienie jego architektury i stanowiący przewodnik do jego budowy podczas następnych faz. 2. Budowa listy cech (Build Feature List) Na podstawie wiedzy zgromadzonej podczas pierwszego etapu, tworzona jest lista cech, będącymi funkcjonalnościami systemu. Cechy te są małymi kawałkami, pełniącymi funkcje użytkowe, wyrażane poprzez pojedyncze zdanie np.: Sprawdź poprawność hasła użytkownika, czy Oblicz sumę wszystkich wartości. Każda taka cech nie powinna zająć więcej niż 2 tygodnie tworzenia. 3. Planowanie wg cech (Plab by Feature) Na podstawie listy cech konstruowany jest plan tworzenia oprogramowania. Głównym programistom przyporządkowywane są cechy lub zestawy cech jako klasy. Każda z klas ma właściciela. 4. Projekt wg cech (Design by Feature) Tworzone są zespoły złożone z właścicieli klas. Zespoły wykonują szczegółowe projekty, dopracowując ogólny model. Następnie, przeprowadzane są inspekcje projektów. 5. Implementacja wg cech (Build by Feature) zaakceptowane projekty są kodowane przez właścicieli klas. Po przejściu testów dodawane są do głównego systemu, który prezentowany jest klientowi. Dwa ostatnie punkty powtarza się iteracyjnie do końca projektu.

29 Ponieważ poszczególne cechy są relatywnie prostymi zadaniami, w celu śledzenia rozwoju projektu i dokładnego raportowania stanu definiowane są tzw. kamienie milowe. FDD definiuje sześć kamieni milowych dla każdej cechy, które muszą być ukończone sekwencyjnie. Pierwsze trzy zawierają się w fazie Projekt wg cech, kolejne trzy zaś w fazie Implementacja wg cech. Do każdego kamienia milowego przypisywany jest procent ukończenia cechy: 1. Przegląd dziedziny (Domain Walkthrough) 1% 2. Projekt (Design) 40% 3. Inspekcja projektu (Design Inspection) 3% 4. Kod (Code) 45% 5. Inspekcja kodu (Code Inspection) 10% 6. Dodanie do wersji (Promote to Build) 1%

30 Dobre praktyki składające się na FDD: 1. Domain Object Modeling (DOM) - składa się z badania i wyjaśniania dziedziny rozwiązywanego problemu. Wynikowy model dostarcza ogólnego szablonu, do którego dodawane są cechy. 2. Tworzenie wg cech (Developing by Feature) Każda funkcja, której nie da się zaimplementować w 2 tygodnie jest rozkładana na mniejsze problemy. 3. Indywidualni właściciele klas (Individual Class Ownership) oznacza, że odrębne fragmenty kodu są przypisane do pojedynczych właścicieli, odpowiedzialnych za zgodność, wydajność i integralność klas. 4. Zespoły przypisywane do cech (Feature Teams) są małe, dynamicznie formowane, przez co nad każdą decyzją projektową zastanawia się wiele osób. 5. Inspekcje zapewniają wysoką jakość projektów i kodów źródłowych. 6. Zarządzanie konfiguracją (Configuration Management) pomaga przy identyfikacji kodów źródłowych ukończonych cech oraz rejestrowaniu historii zmian dokonywanych w cechach. 7. Regularnie wypuszczane wersje (Regular Builds) zapewniają, że zawsze istnieje aktualna wersja systemu, którą można pokazać klientowi, a także pomaga wcześnie odnajdować błędy integracji kodu źródłowego 8. Widoczność postępów (Visibility of progress and results) dzięki częstym i celnym raportom na wszystkich poziomach; pomocne przy kierowaniu projektem.

31 Test Driven Development (TDD) Jest techniką tworzenia oprogramowania zaliczaną do metodyk zwinnych. Została stworzona przez Kenta Becka. Pierwotnie była częścią programowania ekstremalnego (Extreme Programming), lecz obecnie stanowi samodzielną technikę. Polega na wielokrotnym powtarzaniu kilku kroków. 1. Najpierw programista pisze automatyczny test sprawdzający dodawaną funkcjonalność. Test w tym momencie nie powinien się udać. 2. Później następuje implementacja funkcjonalności. W tym momencie wcześniej napisany test powinien się udać. 3. W ostatnim kroku, programista dokonuje refaktoryzacji napisanego kodu, żeby spełniał on oczekiwane standardy.

32 Cykl wytwórczy TDD składa się z następujących kroków: 1. Dodaj test każda nowa funkcjonalność rozpoczyna się od napisania testu, który musi na początku się nie udać. Aby stworzyć test twórca musi dokładnie zrozumieć specyfikę funkcjonalności oraz jej wymagania. Dzięki temu skupia się on na wymaganiach jeszcze przed napisaniem kodu. Możliwy jest wariant, w którym twórca tylko modyfikuje istniejący test. 2. Przeprowadź wszystkie testy i sprawdź, czy nowy się nie udał dzięki temu można się przekonać czy nowy test działa poprawnie i błędnie nie akceptuje poprzedniego kodu bez wprowadzonych zmian. 3. Napisz trochę kodu taki aby przeszedł test. Nie musi on być idealny. Jest to dopuszczalne, ponieważ dalsze kroki to poprawią. 4. Przeprowadź testy i sprawdź czy się powiodły jeśli tak, to kod spełnia wymagania. 5. Refaktoryzuj kod dzięki czemu będzie czystszy. Poprzez ponowne przeprowadzanie testów, można się upewnić, że wprowadzone zmiany nie niszczą istniejącej funkcjonalności. 6. Powtórz zaczynając od kolejnego nowego testu, cykl się powtarza, aby rozszerzać funkcjonalność.

33 (Prze)Twórz test Udaje się Powtórz Przeprowadź testy Nie udaje się Napisz trochę kodu Nie udaje się Przeprowadź testy Udaje się Wyczyść kod

34 Programowanie ekstremalne (Extreme Programming, XP) Jest techniką tworzenia oprogramowania zaliczaną do metodyk zwinnych, która w zamierzeniach ma poprawę jakości oprogramowania oraz reakcje na zmiany wymagań klienta. Została ona stworzona przez Kenta Becka i opisana w jego książce Extreme Programming Explained z 1999 roku. XP próbuje zredukować koszty zmian wymagań poprzez wiele krótkich cykli wytwarzania oprogramowania, zamiast jednego jak np. w kaskadowym modelu. Według tej metodyki zmiany są naturalnym, nieuniknionym i wskazanym aspektem projektu oraz powinny być włączone w plany projektu, zamiast próby stworzenia niezmiennego zestawu wymagań.

35 Ekstremalne programowanie opisuje 4 podstawowe czynności podczas procesu wytwarzania oprogramowania: 1. Tworzenie kodu źródłowego według zwolenników XP jedynym naprawdę istotnym produktem procesu wytwarzania systemu jest kod źródłowy. Czynność ta może być dodatkowo wykorzystana do wynajdywania najbardziej odpowiadających rozwiązań, a także do komunikacji. Programista, który nie potrafi słownie wytłumaczyć sposobu rozwiązania jakiegoś problemu, może użyć kodu źródłowego do zademonstrowania innym programistom. 2. Testowanie nie można być pewnym czy dana funkcja działa poprawnie dopóki nie zostanie przetestowana. Poprzez testowanie można wykryć wiele błędów. Wyróżnia się dwa rodzaje testów: Testy jednostkowe sprawdzające czy dana funkcjonalność działa poprawnie. Programista pisze tak wiele zautomatyzowanych testów, jak tylko potrafi wymyśleć. Jeśli kod przejdzie wszystkie testy jest akceptowany. Testy akceptacyjne weryfikujące czy wymagania zrozumiane przez programistów spełniają właściwe wymagania klientów 3. Słuchanie programiści muszą słuchać, czego klienci oczekują od systemów, jaka logika biznesowa jest potrzebna. Muszą rozumieć te potrzeby na tyle, aby móc przedstawić klientom techniczne aspekty tego, jak dane problemy mogą być rozwiązane lub nie.

36 4. Projektowanie Z punktu widzenia prostoty, może wydawać się, że projektowanie jest zbędne i wystarczą tylko pierwsze trzy czynności. Jednak w praktyce jednak, bez projektu, kiedy system staje się zbyt złożony, a zależności przestają być wyraźne. Dobry projekt organizujący logikę w systemie, pozwoli na uniknięcie wielu zależności, dzięki czemu zmiana jednej części systemu nie będzie miała wpływu na działanie innych. Ekstremalne programowanie wyróżnia 4 wartości: 1. Komunikacja Technika ekstremalnego programowania może być postrzegana jako metody szybkiego tworzenia oprogramowania i rozszerzania formalnej wiedzy pomiędzy członkami zespołów programistycznych. Celem jest danie wszystkim twórcom współdzielonego spojrzenia na system, pokrywającego się ze spojrzeniem z perspektywy użytkowników systemu. XP wspiera więc, proste projekty, współpracę między użytkownikami, a programistami, częstą słowną komunikację oraz opinie zwrotne.

37 2. Prostota XP zachęca do zaczynania od najprostszych rozwiązań, a każde dodatkowa funkcjonalność, może być dodana później. Różnica między programowaniem ekstremalnym, a bardziej konwencjonalnymi metodykami jest koncentracja na potrzebach aktualnych, dzisiejszych, a nie tych jutrzejszych, przyszłego tygodnia czy miesiąca. Prosty projekt i kod źródłowy może być dobrze zrozumiany przez większość programistów z zespołu. 3. Opinie zwrotne (Feedback) odnosi się do różnych wymiarów tworzenia systemu od systemu poprzez pisanie testów jednostkowych lub przeprowadzanie okresowych testów integralności od klienta poprzez testy akceptacyjne od zespołu kiedy zachodzą zmiany wymagań klientów, zespół bezpośrednio przekazuje oszacowany czas wymagany do implementacji 4. Odwaga przykładami na wymaganie posiadania odwagi jest rozumienie kiedy należy wyrzucić kod, odwaga by usunąć przestarzały kod, bez względu na to jak wiele pracy zostało włożone w jego stworzenie, odwaga oznaczająca wytrwałość, kiedy programista utknie przy jakimś złożonym problemie, jednak powróci do niego następnego dnia, aby go rozwiązać 5. Szacunek zarówno do innych jak i do siebie. Szanowanie własnej pracy, poprzez staranie się o jak najlepszą jakość i najlepsze rozwiązania. Kiedy nikt nie jest ignorowany, albo niedoceniany wzbudzany jest wysoki poziom motywacji, co także zachęca do lojalności wobec współpracowników.

38 Opis programowanie ekstremalnego zawiera dwanaście praktyk zgrupowanych w kategorie 1. Fine scale feedback Programowanie w parach (Pair programming) Gra w planowanie (Planning game) Test-driven development Cała drużyna (Whole team) 1. Ciągły proces (Continuous process) Ciągłe integrowanie (Continuous integration) Refaktoryzowanie (Refactoring) Małe wydania (Small releases) 1. Wspólne rozumienie (Shared understanding) Standardy programowania (Coding standards) Wspólna własność kodu (Collective Code Ownership) Prosty projekt (Simple design) Metafora systemu (System methaphor) 1. Programing welfare Zrównoważone tempo (Sustainable pace)

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming Jarosław Kuchta Wymagania jakości w Agile Programming Wady klasycznych metod zapewnienia jakości Duży narzut na dokumentowanie Późne uzyskiwanie konkretnych rezultatów Trudność w odpowiednio wczesnym definiowaniu

Bardziej szczegółowo

Programowanie zespołowe

Programowanie zespołowe Programowanie zespołowe Laboratorium 4 - modele tworzenia oprogramowania, manifest Agile i wstęp do Scruma mgr inż. Krzysztof Szwarc krzysztof@szwarc.net.pl Sosnowiec, 14 marca 2017 1 / 21 mgr inż. Krzysztof

Bardziej szczegółowo

Lekkie metodyki. tworzenia oprogramowania

Lekkie metodyki. tworzenia oprogramowania Lekkie metodyki tworzenia oprogramowania Programowanie zwinne ( Agile software development) grupa metodyk wytwarzania oprogramowania opartego o programowanie iteracyjne (model przyrostowy). Wymagania oraz

Bardziej szczegółowo

Feature Driven Development

Feature Driven Development Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami

Bardziej szczegółowo

Etapy życia oprogramowania

Etapy życia oprogramowania Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 w prezentacji wykorzystano również materiały przygotowane przez Michała Kolano

Bardziej szczegółowo

Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania

Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania Etapy życia oprogramowania Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 Określenie wymagań Testowanie Pielęgnacja Faza strategiczna

Bardziej szczegółowo

Programowanie zwinne - wprowadzenie. Programowanie ekstremalne. Wstęp Reguły i praktyki SCRUM. Wprowadzenie Role Zdarzenia Artefakty

Programowanie zwinne - wprowadzenie. Programowanie ekstremalne. Wstęp Reguły i praktyki SCRUM. Wprowadzenie Role Zdarzenia Artefakty Anna Kulig Programowanie zwinne - wprowadzenie Programowanie ekstremalne Wstęp Reguły i praktyki SCRUM Wprowadzenie Role Zdarzenia Artefakty Agile Manifesto 2001 rok, Snowbird w stanie Utah w USA Najważniejsi

Bardziej szczegółowo

Programowanie Zespołowe

Programowanie Zespołowe Programowanie Zespołowe Programowanie zwinne dr Rafał Skinderowicz mgr inż. Michał Maliszewski Programowanie zwinne Grupa metodyk wytwarzania oprogramowania oparta na modelu iteracyjno-obiektowym Powstała

Bardziej szczegółowo

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania prowadzący: dr inż. Krzysztof Bartecki www.k.bartecki.po.opole.pl Proces tworzenia oprogramowania jest zbiorem czynności i

Bardziej szczegółowo

Asynchroniczne interfejsy WWW

Asynchroniczne interfejsy WWW Asynchroniczne interfejsy WWW Metodyki zwinnego wytwarzania oprogramowania mgr inż. Rafał Grycuk Strona służbowa: http://iisi.pcz.pl/~rgrycuk/ Kontakt: rafal.grycuk@iisi.pcz.pl Konsultacje: Środa, 12-14

Bardziej szczegółowo

Metodyki programowania. Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl

Metodyki programowania. Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl Metodyki programowania Tomasz Kaszuba 2015 kaszubat@pjwstk.edu.pl Wybrane metodyki zwinne TRADYCYJNE: RUP (Rational Unified Process) spiralny, rozbudowany PRINCE2 (Projects In Controlled Environments)

Bardziej szczegółowo

SCRUM niełatwe wdrażanie metodyki w praktyce. Adam Krosny

SCRUM niełatwe wdrażanie metodyki w praktyce. Adam Krosny SCRUM niełatwe wdrażanie metodyki w praktyce Adam Krosny 1 Czym się zajmujemy Realizujemy projekty informatyczne średniej wielkości Ilość osób w projekcie 10-50 Architektura SOA, EBA Wiele komponentów

Bardziej szczegółowo

Projektowanie systemów informatycznych. wykład 6

Projektowanie systemów informatycznych. wykład 6 Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany

Bardziej szczegółowo

Wprowadzenie do metodyki SCRUM. mgr inż. Remigiusz Samborski Instytut Informatyki Politechnika Wrocławska

Wprowadzenie do metodyki SCRUM. mgr inż. Remigiusz Samborski Instytut Informatyki Politechnika Wrocławska Wprowadzenie do metodyki SCRUM mgr inż. Remigiusz Samborski Instytut Informatyki Politechnika Wrocławska SCRUM Scrum (skrót od scrummage) - metoda ponownego uruchomienia gry w rugby zwana również formacją

Bardziej szczegółowo

Zarządzanie projektami. Porównanie podstawowych metodyk

Zarządzanie projektami. Porównanie podstawowych metodyk Zarządzanie projektami Porównanie podstawowych metodyk Porównanie podstawowych metodyk w zarządzaniu projektami PRINCE 2 PMBOK TENSTEP AGILE METODYKA PRINCE 2 Istota metodyki PRINCE 2 Project IN Controlled

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering)

Inżynieria oprogramowania (Software Engineering) Inżynieria oprogramowania (Software Engineering) Wykład 2 Proces produkcji oprogramowania Proces produkcji oprogramowania (Software Process) Podstawowe założenia: Dobre procesy prowadzą do dobrego oprogramowania

Bardziej szczegółowo

Wykład 2. MIS-1-505-n Inżynieria oprogramowania Marzec 2014. Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

Wykład 2. MIS-1-505-n Inżynieria oprogramowania Marzec 2014. Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie Wykład 2 MIS-1-505-n Inżynieria Marzec 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 2.1 Agenda 1 2 3 4 5 6 2.2 Czynności w czasie produkcji. Inżynieria stara się zidentyfikować

Bardziej szczegółowo

Podejście tradycyjne. plan wykonanie sekwencyjna natura wykonywanych zadań

Podejście tradycyjne. plan wykonanie sekwencyjna natura wykonywanych zadań Metodyka Scrum Podejście tradycyjne plan wykonanie sekwencyjna natura wykonywanych zadań analiza i definiowanie wymagań projektowanie rozwiązań kodowanie rozwiązań testowanie odstępstwo od planu jest kosztowne

Bardziej szczegółowo

Metodyki zwinne wytwarzania oprogramowania

Metodyki zwinne wytwarzania oprogramowania Metodyki zwinne wytwarzania oprogramowania Wykład 1 Marcin Młotkowski 7 października 2014 Plan wykładu Sprawy organizacyjne Organizacja pracowni 1 Sprawy organizacyjne Organizacja pracowni 2 3 Marcin Młotkowski

Bardziej szczegółowo

Cykle życia systemu informatycznego

Cykle życia systemu informatycznego Cykle życia systemu informatycznego Cykl życia systemu informatycznego - obejmuję on okres od zgłoszenia przez użytkownika potrzeby istnienia systemu aż do wycofania go z eksploatacji. Składa się z etapów

Bardziej szczegółowo

Scrum. Zwinna metodyka prowadzenia projektów

Scrum. Zwinna metodyka prowadzenia projektów Scrum Zwinna metodyka prowadzenia projektów Plan prezentacji 1. Ogólna idea 2. Najważniejsze elementy 3. Role 4. Czynności 5. Artefakty 6. Wnioski 7. Literatura Źródło ilustracji: http://commons.wikimedia.org/wiki/file:scrum.jpg

Bardziej szczegółowo

Akademia ADB Wykład I Praca w grupie i jakość kodu

Akademia ADB Wykład I Praca w grupie i jakość kodu Akademia ADB Wykład I Praca w grupie i jakość kodu Ale zanim zaczniemy... https://www.adbglobal.com/adb-tech-talk/ Wtorek, 24 X 2017, 18:00 w Filharmonii Zielonogórskiej Kto pracuje nad projektem? Nad

Bardziej szczegółowo

Programowanie zwinne

Programowanie zwinne Programowanie zwinne Wykład 1 Marcin Młotkowski 10 października 2012 Plan wykładu Sprawy organizacyjne Organizacja pracowni 1 Sprawy organizacyjne Organizacja pracowni 2 3 Marcin Młotkowski Programowanie

Bardziej szczegółowo

MODELE CYKLU ŻYCIA OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś

MODELE CYKLU ŻYCIA OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś (często stosowany w praktyce do projektów o niewielkiej złożoności) wymagania specyfikowanie kodowanie

Bardziej szczegółowo

Metody wytwarzania oprogramowania. Metody wytwarzania oprogramowania 1/31

Metody wytwarzania oprogramowania. Metody wytwarzania oprogramowania 1/31 Metody wytwarzania oprogramowania Metody wytwarzania oprogramowania 1/31 Metody wytwarzania oprogramowania 2/31 Wprowadzenie Syndrom LOOP Late Późno Over budget Przekroczono budżet Overtime nadgodziny

Bardziej szczegółowo

Planowanie i realizacja zadań w zespole Scrum

Planowanie i realizacja zadań w zespole Scrum MetaPack IT Academy Uniwersytet Zielonogórski Planowanie i realizacja zadań w zespole Scrum Paweł Przybyła Professional Scrum Master (www.scrum.org) Planowanie i realizacja zadań w zespole Scrum Agenda:

Bardziej szczegółowo

Wskazówki projektowe. Programowanie Obiektowe Mateusz Cicheński

Wskazówki projektowe. Programowanie Obiektowe Mateusz Cicheński Wskazówki projektowe Programowanie Obiektowe Mateusz Cicheński Przydatne zasady SOLID Wzorce struktury aplikacji MVC MVP MVVM Metody wytwarzania oprogramowania Manifest Zwinnego Wytwarzania Oprogramowania

Bardziej szczegółowo

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej Wykład VII - semestr III Kierunek Informatyka Wydział Matematyki Stosowanej Politechniki Śląskiej Gliwice, 2014 c Copyright 2014 Janusz Słupik Wytwarzanie oprogramowania Model tworzenia oprogramowania

Bardziej szczegółowo

Agile Project Management

Agile Project Management Charles G. Cobb, pmp Zrozumieć Agile Project Management Równowaga kontroli i elastyczności przekład: Witold Sikorski APN Promise Warszawa 2012 Spis treści Wstęp...vii Kto powinien przeczytać tę książkę?...

Bardziej szczegółowo

Programowanie Zespołowe

Programowanie Zespołowe Programowanie Zespołowe Dobre Praktyki dr Rafał Skinderowicz mgr inż. Michał Maliszewski Parafrazując klasyka: Jeśli piszesz w Javie pisz w Javie - Rafał Ciepiela Principal Software Developer Cadence Design

Bardziej szczegółowo

Projektowanie systemów informatycznych. Roman Simiński programowanie.siminskionline.pl. Cykl życia systemu informatycznego

Projektowanie systemów informatycznych. Roman Simiński programowanie.siminskionline.pl. Cykl życia systemu informatycznego systemów informatycznych Roman Simiński roman.siminski@us.edu.pl programowanie.siminskionline.pl Cykl życia systemu informatycznego Trochę wprowadzenia... engineering co to oznacza? Oprogramowanie w sensie

Bardziej szczegółowo

Techniki komputerowe w robotyce

Techniki komputerowe w robotyce Techniki komputerowe w robotyce Wykład V Adaptacyjne zarządzanie projektami Robert Muszyński KCiR, W4, PWr Skład FoilTEX c R. Muszyński 2009-2015 Metodologie prowadzenia projektu Dążenie do opracowania

Bardziej szczegółowo

Waterfall model. (iteracyjny model kaskadowy) Marcin Wilk

Waterfall model. (iteracyjny model kaskadowy) Marcin Wilk Waterfall model (iteracyjny model kaskadowy) Marcin Wilk Iteracyjny model kaskadowy jeden z kilku rodzajów procesów tworzenia oprogramowania zdefiniowany w inżynierii oprogramowania. Jego nazwa wprowadzona

Bardziej szczegółowo

Wytwarzanie oprogramowania

Wytwarzanie oprogramowania AiPA 6 Wytwarzanie oprogramowania Proces tworzenia oprogramowania jest procesem przekształcenia wymagań w oprogramowanie zgodnie z metodyką, która określa KTO CO robi JAK i KIEDY. - Wymagania Proces tworzenia

Bardziej szczegółowo

Zarządzanie projektami. Wykład 2 Zarządzanie projektem

Zarządzanie projektami. Wykład 2 Zarządzanie projektem Zarządzanie projektami Wykład 2 Zarządzanie projektem Plan wykładu Definicja zarzadzania projektami Typy podejść do zarządzania projektami Cykl życia projektu/cykl zarządzania projektem Grupy procesów

Bardziej szczegółowo

szkolenia pod drzewem Wybrane Techniki XP bnd 2008 Tomasz Włodarek. Materiał udostępniany na podstawie licencji Creative Commons (by-nc-nd) 1.00.

szkolenia pod drzewem Wybrane Techniki XP bnd 2008 Tomasz Włodarek. Materiał udostępniany na podstawie licencji Creative Commons (by-nc-nd) 1.00. szkolenia pod drzewem Wybrane Techniki XP 1.00.00 bnd Wybrane techniki XP współwłasność kodu źródłowego (collective code ownership) częsta/ciągła integracja (continuous integration) programowanie w parach

Bardziej szczegółowo

SCRUM. Metodyka prowadzenia projektów. Na podstawie prezentacji B. Kuka i W. Sidora

SCRUM. Metodyka prowadzenia projektów. Na podstawie prezentacji B. Kuka i W. Sidora SCRUM Metodyka prowadzenia projektów Na podstawie prezentacji B. Kuka i W. Sidora Wprowadzenie. Scrum jest metodyką prowadzenia projektów zaliczaną do metodyk zwinnych, zgodnych z Agile Manifesto. Scrum

Bardziej szczegółowo

Zagadnienia. Inżynieria Oprogramowania

Zagadnienia. Inżynieria Oprogramowania Zagadnienia Co to jest extreme Programming (XP) Czym charakteryzują się tzw. lekkie metodyki zarządzania procesem produkcji oprogramowania Reguły i praktyki XP Dlaczego i kiedy można a w jakich przypadkach

Bardziej szczegółowo

Projektowanie oprogramowania. Termin zajęć: poniedziałek, 18.00-19.45. a podstawie materiału ze strony. http://gromit.iiar.pwr.wroc.

Projektowanie oprogramowania. Termin zajęć: poniedziałek, 18.00-19.45. a podstawie materiału ze strony. http://gromit.iiar.pwr.wroc. Projektowanie oprogramowania Termin zajęć: poniedziałek, 18.00-19.45 a podstawie materiału ze strony http://gromit.iiar.pwr.wroc.pl/p_inf/ Przebieg realizacji projektu (tabela 1) Nr tygo dnia Spotkanie

Bardziej szczegółowo

RUP. Rational Unified Process

RUP. Rational Unified Process RUP Rational Unified Process Agenda RUP wprowadzenie Struktura RUP Przepływy prac w RUP Fazy RUP RUP wprowadzenie RUP (Rational Unified Process) jest : Iteracyjną i przyrostową metodyka W pełni konfigurowalną

Bardziej szczegółowo

Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania

Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania dr inż. Marcin Szlenk Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Wprowadzenie O mnie dr inż. Marcin

Bardziej szczegółowo

Przedsięwzięcia Informatyczne w Zarządzaniu

Przedsięwzięcia Informatyczne w Zarządzaniu Przedsięwzięcia Informatyczne w Zarządzaniu 2005/06 dr inż. Grażyna Hołodnik-Janczura GHJ 1 LITERATURA 1. Praca zbiorowa p.r. Górski J., Inżynieria oprogramowania, MIKOM, W-wa, 2000 2. Jaszkiewicz A.,

Bardziej szczegółowo

Opis realizacji dla czterech zespołów (4 przypadki użycia)

Opis realizacji dla czterech zespołów (4 przypadki użycia) Projektowanie oprogramowania Termin zajęć: czwartek, sala L2.6, C16 7.30-9.00, 9.15-10.45 Na podstawie materiału ze strony http://gromit.iiar.pwr.wroc.pl/p_inf/ Przebieg realizacji projektu (tabela 1)

Bardziej szczegółowo

Ogólne określenie wymagań. Ogólny projekt. Budowa systemu. Ocena systemu. Nie. Tak. System poprawny. Wdrożenie. Określenie.

Ogólne określenie wymagań. Ogólny projekt. Budowa systemu. Ocena systemu. Nie. Tak. System poprawny. Wdrożenie. Określenie. Inżynieria I Andrzej Jaszkiewicz Kontakt Andrzej Jaszkiewicz p. 8, CW Berdychowo tel. 66 52 933 ajaszkiewicz@cs.put.poznan.pl Rynek 2008 Świat 304 miliardy $ (451 miliardów 2013F) Bez wytwarzanego na własne

Bardziej szczegółowo

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................

Bardziej szczegółowo

Rozpoczęcie, inicjacja (ang. inception

Rozpoczęcie, inicjacja (ang. inception Wydział Informatyki PB Analogia do budowanego domu Inżynieria oprogramowania II Wykład 2: Proces tworzenia oprogramowania (na podstawie Unified Process) Marek Krętowski pokój 206 e-mail: mkret@ii.pb.bialystok.pl

Bardziej szczegółowo

Scrum w praktyce. Michał Piórek

Scrum w praktyce. Michał Piórek Scrum w praktyce Michał Piórek Slajd 2 z 28 Plan prezentacji Scrum metodyka prowadzenia projektów Opis projektu systemu do rozliczania podatków Struktura zespołu i jego role Zespół w firmie Podatnik.info

Bardziej szczegółowo

Testujemy dedykowanymi zasobami (ang. agile testers)

Testujemy dedykowanymi zasobami (ang. agile testers) Testujemy dedykowanymi zasobami (ang. agile testers) - wspólne standupy; - ten sam manager; - duży przepływ informacji; - po pewnym czasie zanika asertywność; - pojawia się tendencja do nie zgłaszania

Bardziej szczegółowo

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania prowadzący: dr hab. inż. Krzysztof Bartecki, prof. PO www.k.bartecki.po.opole.pl Egzamin: część teoretyczna Test jednokrotnego

Bardziej szczegółowo

Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią

Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią Marek Bieniasz Sławomir Umpirowicz Piotr Miszewski Kraków, 10 13 września 2012 Plan prezentacji Informacje

Bardziej szczegółowo

Zakres wykładu. Podstawy InŜynierii Oprogramowania

Zakres wykładu. Podstawy InŜynierii Oprogramowania Zakres wykładu Pojęcia podstawowe InŜynierii Oprogramowania Proces wytwarzania oprogramowania Artefakty procesu wytwarzania i ich modele Jakość oprogramowania Literatura: [1] Sacha K., InŜynieria oprogramowania,

Bardziej szczegółowo

RATIONAL UNIFIED PROCESS. Opis metodyki i procesu produkcji oprogramowania

RATIONAL UNIFIED PROCESS. Opis metodyki i procesu produkcji oprogramowania RATIONAL UNIFIED PROCESS Opis metodyki i procesu produkcji oprogramowania RATIONAL UNIFIED PROCESS Rational Unified Process (RUP) to proces iteracyjnego wytwarzania oprogramowania opracowany przez firmę

Bardziej szczegółowo

Podejście zwinne do zarządzania projektami

Podejście zwinne do zarządzania projektami Podejście zwinne do zarządzania projektami na przykładach projektów wytwarzania oprogramowania Wojciech Czujowski, Łukasz Sienkiewicz Tieto Poland Agenda CZĘŚĆ I-sza: Kilka słów o Tieto SCRUM w organizacji

Bardziej szczegółowo

Oferta szkoleń firmy Code Sprinters

Oferta szkoleń firmy Code Sprinters Oferta szkoleń firmy Code Sprinters Code Sprinters sp z o.o. Królewska 2/2 Kraków Telefon +48 12 379 34 14 Fax +48 12 379 34 11 info@codesprinters.com www.codesprinters.com Jako liderzy na rynku szkoleń

Bardziej szczegółowo

Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka

Agile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka Agile vs PRINCE2 Ewa Solecka - specjalność ogólna- 1117627 Przemysław Mrozowski specjalność ogólna- 1121130 Michał Roztoczyński specjalność ogólna - 1118910 2014/2015 I rok st. magisterskie Informatyka

Bardziej szczegółowo

Zarządzanie projektami. Porównanie podstawowych metodyk

Zarządzanie projektami. Porównanie podstawowych metodyk Zarządzanie projektami Porównanie podstawowych metodyk Porównanie podstawowych metodyk w zarządzaniu projektami PRINCE 2 PMBOK TENSTEP AGILE METODYKA PRINCE 2 Istota metodyki PRINCE 2 Project IN Controlled

Bardziej szczegółowo

Rational Unified Process. Dokładny opis metodyki i procesu produkcji oprogramowania

Rational Unified Process. Dokładny opis metodyki i procesu produkcji oprogramowania Rational Unified Process Dokładny opis metodyki i procesu produkcji oprogramowania Rational Unified Process (RUP). RUP jest iteracyjnym procesem rozwoju oprogramowania. Definiuje szkielet postępowania,

Bardziej szczegółowo

Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki

Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework Edyta Tomalik Grzegorz Ziemiecki 1 Nokia Siemens Networks 2013 Tradycyjne podejście analityk programista tester implementacja

Bardziej szczegółowo

Usługa: Audyt kodu źródłowego

Usługa: Audyt kodu źródłowego Usługa: Audyt kodu źródłowego Audyt kodu źródłowego jest kompleksową usługą, której głównym celem jest weryfikacja jakości analizowanego kodu, jego skalowalności, łatwości utrzymania, poprawności i stabilności

Bardziej szczegółowo

INŻYNIERIA OPROGRAMOWANIA LAB 1

INŻYNIERIA OPROGRAMOWANIA LAB 1 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

Bardziej szczegółowo

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką? ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest

Bardziej szczegółowo

Wstęp do zarządzania projektami

Wstęp do zarządzania projektami Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.

Bardziej szczegółowo

INŻYNIERIA OPROGRAMOWANIA Metodyki zarządzania projektem - porównanie

INŻYNIERIA OPROGRAMOWANIA Metodyki zarządzania projektem - porównanie Wykład 3 (8) Metodyka prowadzenia PI zbiór reguł i zaleceń określających sposób organizacji procesu wytwarzania oprogramowania, powstające artefakty i zakres zaangażowania uczestników procesu Metodyki

Bardziej szczegółowo

MSF. Microsoft Solution Framework

MSF. Microsoft Solution Framework MSF Microsoft Solution Framework MSF a PMI PMI - metodyka podobna dla każdego rodzaju projektów MSF metodyka przeznaczona dla projektów informatycznych mająca cechy PMI MSF metodyka utworzona na podstawie

Bardziej szczegółowo

Wytwórstwo oprogramowania. michał możdżonek

Wytwórstwo oprogramowania. michał możdżonek Wytwórstwo oprogramowania michał możdżonek 01.2008 Plan wykładu 1. Proces tworzenie oprogramowania 2. Zarządzanie projektami 3. Wymagania 4. Projektowanie 5. Testowanie 6. Szacowanie złożoności i kosztu

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy

Bardziej szczegółowo

Testowanie oprogramowania

Testowanie oprogramowania Testowanie oprogramowania 1/17 Testowanie oprogramowania Wykład 01 dr inż. Grzegorz Michalski 13 października 2015 Testowanie oprogramowania 2/17 Dane kontaktowe: Kontakt dr inż. Grzegorz Michalski pokój

Bardziej szczegółowo

Modelowanie i analiza systemów informatycznych

Modelowanie i analiza systemów informatycznych Modelowanie i analiza systemów informatycznych MBSE/SysML Wykład 11 SYSMOD Wykorzystane materiały Budapest University of Technology and Economics, Department of Measurement and InformaJon Systems: The

Bardziej szczegółowo

Podstawy programowania III WYKŁAD 4

Podstawy programowania III WYKŁAD 4 Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.

Bardziej szczegółowo

Egzamin / zaliczenie na ocenę*

Egzamin / zaliczenie na ocenę* WYDZIAŁ PODSTAWOWYCH PROBLEMÓW TECHNIKI Zał. nr 4 do ZW33/01 KARTA PRZEDMIOTU Nazwa w języku polskim : INŻYNIERIA OPROGRAMOWANIA Nazwa w języku angielskim: SOFTWARE ENGINEERING Kierunek studiów (jeśli

Bardziej szczegółowo

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN Podziękowania REQB Poziom Podstawowy Przykładowy Egzamin Dokument ten został stworzony przez główny zespół Grupy Roboczej REQB dla Poziomu Podstawowego. Tłumaczenie

Bardziej szczegółowo

Zarządzanie projektami w NGO

Zarządzanie projektami w NGO Zarządzanie projektami w NGO Warsztaty dla Grupy Nowe Technologie Federacja Organizacji Służebnych MAZOWIA 4 września 2012 Projekt współfinansowany jest ze środków Unii Europejskiej w ramach Europejskiego

Bardziej szczegółowo

Zagadnienia. Inżynieria Oprogramowania

Zagadnienia. Inżynieria Oprogramowania Zagadnienia Co to jest extreme Programming (XP) Czym charakteryzują się tzw. lekkie metodyki zarządzania procesem produkcji oprogramowania Reguły i praktyki XP Dlaczego i kiedy można a w jakich przypadkach

Bardziej szczegółowo

Michał Olejnik. 22 grudnia 2009

Michał Olejnik. 22 grudnia 2009 Continuous TDD Politechnika Wrocławska Informatyka 22 grudnia 2009 Agenda Wprowadzenie 1 Wprowadzenie 2 3 4 5 Agenda Wprowadzenie 1 Wprowadzenie 2 3 4 5 Agenda Wprowadzenie 1 Wprowadzenie 2 3 4 5 Agenda

Bardziej szczegółowo

Wstęp do zarządzania projektami

Wstęp do zarządzania projektami Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.

Bardziej szczegółowo

Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz

Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz Promotor dr inż. Szymon Supernak Warszawa, 22.05.2014 Plan prezentacji 1. Cel i

Bardziej szczegółowo

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki

Bardziej szczegółowo

Jak być agile w projekcie utrzymaniowym? JOANNA SIEMIŃSKA

Jak być agile w projekcie utrzymaniowym? JOANNA SIEMIŃSKA Jak być agile w projekcie utrzymaniowym? JOANNA SIEMIŃSKA Joanna Siemińska o mnie Absolwentka Politechniki Warszawskiej Orange Outbox Europejska Organizacja Badań Jądrowych w Genewie (CERN) TouK Certyfikat

Bardziej szczegółowo

Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny

Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny mgr inż. Kajetan Kurus 15 kwietnia 2014 1 Dostępne techniki programowania Tworząc program należy

Bardziej szczegółowo

SVN. 10 października 2011. Instalacja. Wchodzimy na stronę http://tortoisesvn.tigris.org/ i pobieramy aplikację. Rysunek 1: Instalacja - krok 1

SVN. 10 października 2011. Instalacja. Wchodzimy na stronę http://tortoisesvn.tigris.org/ i pobieramy aplikację. Rysunek 1: Instalacja - krok 1 SVN 10 października 2011 Instalacja Wchodzimy na stronę http://tortoisesvn.tigris.org/ i pobieramy aplikację uruchamiany ponownie komputer Rysunek 1: Instalacja - krok 1 Rysunek 2: Instalacja - krok 2

Bardziej szczegółowo

Wprowadzenie do systemów informacyjnych

Wprowadzenie do systemów informacyjnych Wprowadzenie do systemów informacyjnych Kryteria oceny systemu Podstawowe metody projektowania UEK w Krakowie Ryszard Tadeusiewicz 1 UEK w Krakowie Ryszard Tadeusiewicz 2 Technologia informatyczna dzisiaj

Bardziej szczegółowo

Wstęp do zarządzania projektami

Wstęp do zarządzania projektami Wstęp do zarządzania projektami Definicja projektu Projekt to tymczasowe przedsięwzięcie podejmowane w celu wytworzenia unikalnego wyrobu, dostarczenia unikalnej usługi lub uzyskania unikalnego rezultatu.

Bardziej szczegółowo

REFERAT PRACY DYPLOMOWEJ

REFERAT PRACY DYPLOMOWEJ REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt i implementacja środowiska do automatyzacji przeprowadzania testów aplikacji internetowych w oparciu o metodykę Behavior Driven Development. Autor: Stepowany

Bardziej szczegółowo

Budowa aplikacji webowej w oparciu o Maven2 oraz przykłady testów jednostkowych. Wykonał Marcin Gadamer

Budowa aplikacji webowej w oparciu o Maven2 oraz przykłady testów jednostkowych. Wykonał Marcin Gadamer Budowa aplikacji webowej w oparciu o Maven2 oraz przykłady testów jednostkowych. Wykonał Marcin Gadamer Maven 2 podstawowe informacje Apache Maven jest narzędziem automatyzującym budowę oprogramowania

Bardziej szczegółowo

Zarządzanie projektami. Wykład 2 Czym jest zarządzanie projektami?

Zarządzanie projektami. Wykład 2 Czym jest zarządzanie projektami? Zarządzanie projektami Wykład 2 Czym jest zarządzanie projektami? Plan Czym jest zarządzanie projektami? Jakie są rodzaje podejść do zarządzania projektami? Jakie są grupy procesów w ramach zarządzania

Bardziej szczegółowo

Modele cyklu życia oprogramowania

Modele cyklu życia oprogramowania Anna Kulig Modele cyklu życia oprogramowania Programowanie zwinne Przyczyny powstania Wprowadzenie Programowanie ekstremalne Wstęp Reguły i praktyki AUP krótki opis metodologii Model cyklu życia systemu

Bardziej szczegółowo

SCRUM - FRAMEWORK DO ZWINNEGO PROWADZENIA PROJEKTÓW. Ilona Ławniczak-Tomczak

SCRUM - FRAMEWORK DO ZWINNEGO PROWADZENIA PROJEKTÓW. Ilona Ławniczak-Tomczak SCRUM - FRAMEWORK DO ZWINNEGO PROWADZENIA PROJEKTÓW Ilona Ławniczak-Tomczak AGENDA WPROWADZENIE DO TEMATYKI AGILE OMÓWIENIE METODYKI SCRUM I JEJ ISTOTY ĆWICZENIA WYJAŚNIENIE POWIĄZANIA SCRUM I ZAAWANSOWANYCH

Bardziej szczegółowo

ŚCIEŻKA KRYTYCZNA. W ścieżkach krytycznych kolejne zadanie nie może się rozpocząć, dopóki poprzednie się nie zakończy.

ŚCIEŻKA KRYTYCZNA. W ścieżkach krytycznych kolejne zadanie nie może się rozpocząć, dopóki poprzednie się nie zakończy. ŚCIEŻKA KRYTYCZNA Ciąg następujących po sobie zadań w ramach projektu trwających najdłużej ze wszystkich możliwych ciągów, mających taką własność, że opóźnienie któregokolwiek z nich opóźni zakończenie

Bardziej szczegółowo

Inżynieria oprogramowania II

Inżynieria oprogramowania II Wymagania funkcjonalne, przypadki użycia Inżynieria oprogramowania II Problem i cel Tworzenie projektów bez konkretnego celu nie jest dobre Praktycznie każdy projekt informatyczny powstaje z uwagi na jakiś

Bardziej szczegółowo

Agile Project Management WHITEPAPER

Agile Project Management WHITEPAPER 1 Wstęp... 2 Historia... 2 DSDM ATERN... 3 Agile w zarządzaniu projektami... 4 Szkolenia i certyfikacja... 6 Certyfikaty Agile Project Management Foundation i Practitioner... 6 Szkolenie Agile Project

Bardziej szczegółowo

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:

Bardziej szczegółowo

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Kierunek: Informatyka Modeling and analysis of computer systems Forma studiów: Stacjonarne Rodzaj przedmiotu: obowiązkowy w ramach specjalności:

Bardziej szczegółowo

Wprowadzenie do Behaviordriven

Wprowadzenie do Behaviordriven Wprowadzenie do Behaviordriven development Jakub Kosiński Email: ja@ghandal.net Czym jest BDD? praktyka, powstała na podstawie TDD, wykorzystywana w zwinnych metodykach stworzona przez Dana Northa w 2003

Bardziej szczegółowo

Projekt Kompetencyjny - założenia

Projekt Kompetencyjny - założenia Projekt Kompetencyjny - założenia sem. V 2013 kgrudzi.kis.p.lodz.pl projekt kompetencyjny 1 System informatyczny zbiór powiązanych ze sobą elementów, którego funkcją jest przetwarzanie danych przy użyciu

Bardziej szczegółowo

Luki w bezpieczeństwie aplikacji istotnym zagrożeniem dla infrastruktury krytycznej

Luki w bezpieczeństwie aplikacji istotnym zagrożeniem dla infrastruktury krytycznej Luki w bezpieczeństwie aplikacji istotnym zagrożeniem dla infrastruktury krytycznej Michał Kurek, Partner KPMG, Cyber Security Forum Bezpieczeństwo Sieci Technologicznych Konstancin-Jeziorna, 21 listopada

Bardziej szczegółowo

Maciej Oleksy Zenon Matuszyk

Maciej Oleksy Zenon Matuszyk Maciej Oleksy Zenon Matuszyk Jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów kontroli jakości oprogramowania. Weryfikacja oprogramowania - testowanie zgodności systemu

Bardziej szczegółowo

Rola testów. łatwiej czy trudniej? Wydział MiNI Politechnika Warszawska L.Stapp@mini.pw.edu.pl

Rola testów. łatwiej czy trudniej? Wydział MiNI Politechnika Warszawska L.Stapp@mini.pw.edu.pl Rola testów w metodykach zwinnych łatwiej czy trudniej? Lucjan Stapp Wydział MiNI Politechnika Warszawska L.Stapp@mini.pw.edu.pl o mnie Pracownik naukowy Politechniki Warszawskiej; Autor ponad 40 publikacji,

Bardziej szczegółowo

Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 2004. Zofia Kruczkiewicz

Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 2004. Zofia Kruczkiewicz Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, 2004 Zofia Kruczkiewicz 1. Przedstaw znaczenie oprogramowania we współczesnym świecie 2. Jaki wpływ na ludzi, komunikację

Bardziej szczegółowo

AUREA BPM HP Software. TECNA Sp. z o.o. Strona 1 z 7

AUREA BPM HP Software. TECNA Sp. z o.o. Strona 1 z 7 AUREA BPM HP Software TECNA Sp. z o.o. Strona 1 z 7 HP APPLICATION LIFECYCLE MANAGEMENT Oprogramowanie Application Lifecycle Management (ALM, Zarządzanie Cyklem życia aplikacji) wspomaga utrzymanie kontroli

Bardziej szczegółowo

Zakład Języków Programowania Instytut Informatyki Uniwersytet Wrocławski

Zakład Języków Programowania Instytut Informatyki Uniwersytet Wrocławski INŻYNIERIA OPROGRAMOWANIA wykład 2: MODELE PROCESU WYTWARZANIA OPROGRAMOWANIA dr inż. Leszek Grocholski ( na podstawie wykładów prof. K. Subiety, Instytut Informatyki PAN ) Zakład Języków Programowania

Bardziej szczegółowo