Organizacja - - klucz Moodle IO1902 witryna.mimuw.edu.pl - projekty tworzone na wydziale

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

Download "Organizacja - - klucz Moodle IO1902 witryna.mimuw.edu.pl - projekty tworzone na wydziale"

Transkrypt

1 Inżynieria oprogramowania Strona 1 Organizacja 19 lutego :01 1) 2) 3) klucz Moodle IO1902 witryna.mimuw.edu.pl projekty tworzone na wydziale Laboratoria zespoły mniej więcej 4 osobowe projekt i kompilowany szkielet / prototyp projekt systemu a. wizja b. specyfikacja c. koncepcja d. plan jakości e. plan projektu zarządzanie komunikacją szkielet / prototyp (kompilowalny, uruchamialny) Egzamin pytania testowe wielokrotnego wyboru z punktami ujemnymi uzupełnianie projektowanie ocena koocowa to (~50%) ocena z laba + ocena egzaminu (~50%)

2 Inżynieria oprogramowania Strona 2 Wstęp 19 lutego :36 Inżynieria oprogramowania zastosowanie systematycznego zdyscyplinowanego ilościowego podejście do rozwoju, eksploatacji, utrzymywania oprogramowania inżynieria oprogramowania: wymagania projektowanie walidacja ewolucja procesy Zarządzanie narzędzia API metody formalne systemy specjalne komponenty niezawodnośd dalej: Zarządzanie Projektami Informatycznymi (monograf) Wytwarzanie Systemów Informatycznych (seminarium) Model wodospadowy zadziała przy produkcji sterownika, nie zadziała przy banku internetowym model dobry przy dokładnej specyfikacji smoke test prosty test uruchomieniowy Model prototypowany

3 Inżynieria oprogramowania Strona 3 nadaje się do większych projektów Model przyrostowy ERP Enterprise Rosource Planning iterujemy tworząc kolejne wersje duży projekt składa się z wielu małych model bezpieczny coś będzie działad może nie wszystko, ale jakieś składniki Model ewolucyjny zbieramy wymagania, produkujemy za jakiś czas znów zbieramy wymagania i znów produkujemy kolejną wersję w oparciu o wcześniejsze doświadczenia Model spiralny

4 Inżynieria oprogramowania Strona 4 budżet rośnie z czasem, tworzymy kolejne wersje zgodnie z napływającymi wymaganiami de facto Agile Model V analiza i projektowanie, później testowanie i integracja, testy i integracja silnie związane z powstawaniem wymagao Model UP (Unified Process)

5 Inżynieria oprogramowania Strona 5 Rational planowanie wstępne, iteracje analizy, zbierania wymagao i produkcji, wersja ostateczna filozofia jest taka, że cały czas zajmujemy się wszystkim, ale z różnym natężeniem cały czas utrzymujemy skompilowany system, testy itd. nightly build projekt cały czas się kompiluje Model CMMI (Capability Maturity Model Integration) model porównywania dostawców na każdym poziomie znajdują się praktyki, które są realizowane przez dostawcę Model XP (extreme Programming) klient wymienia cechy oprogramowania programista ustala zadania i pracochłonnośd programiści programują w parach Przygotowują testy jednostkowe Dodają funkcjonalnośd sprawdzając testy jednostkowe Naprawiają błędy jeśli testy są spełnione później integracja i produkcja klient ustala zadania do zrealizowania w najbliższym wydaniu klient prowadzi testy akceptacyjne programiści uaktualniają model szacowania pracochłonności na podstawie zebranych

6 Inżynieria oprogramowania Strona 6 programiści uaktualniają model szacowania pracochłonności na podstawie zebranych doświadczeo Esencja

7 Inżynieria oprogramowania Strona 7 Specyfikacje 26 lutego :45 Model a metodyka model ma za zadanie upraszczad diagram bardzo ogólny model to nie programowanie wizualne metodyka zbiór dobrych praktyk Podejście abstrakcja dekompozycja Analiza i projektowanie analiza znajdowanie i opisywanie bytów / pojęd z dziedzin problemu projektowanie definiowanie elementów oprogramowania i sposób, w jaki b ędą współpracowad w celu spełnienia wymagao specyfikacja odpowiada na pytanie "co" definicja problemu umowa pomiędzy dostawcą a zamawiającym projekt odpowiada na pytanie "jak" definicja rozwiązania czego chcemy uniknąd optimist of yought: We can do it over the weekend Marine Corps mentality: Real programmers don't need sleep metodyki o różnym poziomie formalizmu lekkie (small scale projects, 3 6 osób, 3 6 miesięcy) Agile Software Development (metodyka adaptacyjne) zasady dostosowywane w trakcie średnie(medium scale projects, osób, 1 2 lata) Unified Process ciężkie (large scale projects, osób, 3 5 lat) Capability Maturity Model Integration projekt jest dostosowywany do metodyki Agile Software Development wymaganie będą się zmieniad trzeba pracowad ze zamawiającymi softwarem miarą postępu w projekcie jest działający software jakośd zapewniana poprzez prostotę projektu Capability Maturity Moodel Integration bardzo formalnie dokładne opisy procesu decyzyjnego Unified Process

8 Inżynieria oprogramowania Strona 8 Unified Process 1) 2) 3) business modeling dobre rozpoznanie rzeczywistości requirements rozpoznanie wymagao software należy robid iteracyjnie configuration & change managemt konfiguracja czy pasuje do siebie kompilator, system i kod oprogramowanie należy dzielid na komponenty implementacje <> interfejsy implementacja komunikują się ze sobą tylko za pomocą interfejsów projektowanie wizualne Specyfikacja forma kontraktu pomiędzy producentem a klientem pomiędzy zarządzającymi a programistami pomiędzy architektami a programistami jest potrzebna gdy: istnieje niebezpieczeostwo niezrozumienie się gdy realizujemy potrzeby więcej niż jednej osoby gdy więcej niż jedna osoba pracuje nad projektem staramy się unikad założeo niejawnych i ogólników (duży ekran) scenariusze Przykład dobrej praktyki budujemy drzewo wizja powinna byd definiowana czasem, który chcemy przeznaczyd na jej tworzenie np. spisujemy to, o wymyślimy przez tydzieo procesy biznesowe czynności poza systemem automatyzacja przypadki użycia aktorzy scenariusz główny scenariusze alternatywne modele zależności Modle a metodyka model > co?

9 Inżynieria oprogramowania Strona 9 1) 2) 3) Modle a metodyka model > co? metodyka > jak? problem kompletności oprogramowania czy zrobiliśmy wszystko, co trzeba czy programiści napiszą to, co trzeba Budowa wizji podejście wszerz, a nie wgłąb wymagania systemowe funkcjonalne pozafunkcjonalne słownikowe ograniczenia wymagania zamawiającego wizja systemu Wizja problem możliwe rozwiązania wybranie rozwiązania budowa systemu IT opis działania organizacji za pomocą procesów biznesowych przykłady wymagao pozafunkcjonalnych wersje językowe przyjaznośd użytkownikowi zdarzenia losowe niezawodnośd wydajnośd wymagania powinny zostad zdefiniowane w sposób weryfikowalny Inżynieria wymagao etapy: 1) wydobywanie wymagao w oparciu o model biznesu 2) analiza i negocjacja wymagao 3) zatwierdzanie wymagao 4) zarządzanie zmianami wymagao Specyfikacja specyfikacja jest rodzajem kontraktu oprogramowanie musi byd wyspecyfikowane gdy: istnieje niebezpieczeostwo niezrozumienia lub zapomnienia o potrzebach klienta reprezentowane są potrzeby więcej niż jednej osoby więcej niż jedna osoba wytwarza oprogramowanie kolejnośd działao: 1) wizja 2) procesy biznesowe 3) przypadki użycia 2 i 3 opisują funkcjonalnośd poza tym należy jeszcze pomyśled o wymaganiach pozafunkcjonalnych Proces biznesowy ludzki opis procedury musi wynikad z wizji scenariusz wykonywania systemu z punktu widzenia firmy Przypadek użycia powinien wynikad z procesu biznesowego scenariusz wykonania z punktu widzenia systemu

10 Inżynieria oprogramowania Strona 10 scenariusz wykonania z punktu widzenia systemu niekiedy zdarzenia prowadząc w różnych kierunkach (w zależności od decyzji użytkownika) scenariusz to jedno z wystąpieo przypadku użycia scenariusz główny podstawowy przebieg przypadku użycia scenariusze alternatywny inne przebiegi przypadku użycia budowa dobrego przypadku użycia fraza czasownikowa w nazwie aktor, scenariusz, rozszerzenia nadrzędny cel czytelnośd scenariusz główny najbardziej prawdopodobna ścieżka alternatywne scenariusze kiedy coś pójdzie nie tak obojętnośd technologiczna Wizja składniki: 1) postawienie problemu 2) motto dla systemu 3) osoby zainteresowane, kluczowi użytkownicy 4) główne cechy oprogramowania 5) główne ograniczenia środowiska FURPS: wymagania funkcjonalne functionality usability wymagania pozafunkcjonalne reliability performance security Functionality Feature set, Capabilities, Generality, Security Usability Human factors, Aesthetics, Consistency, Documentation Reliability Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure Performance Speed, Efficiency, Resource consumption, Throughput, Response time Supportability Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Portability Wymagania pozafunkcjonalne przenośnośd efektywnośd komunikatywnośd ustrukturyzowanie wydajnośd odpornośd na błędy modularnośd Dobra specyfikacja poprawnośd czy tak ma działad system czy są to faktyczne wymagania jednoznacznośd czy wymagania mają tylko jedną interpretację każde stwierdzenie może byd odczytane dokładnie w jeden sposób pojęcia mylące definiowane są w słowniku jest przejrzysta (zrozumiała dla nieinformatyków) kompletnośd czy zamieszczono wszystkie wymagania funkcjonalne i pozafunkcjonalne brak elementów wymagających uzupełnienia (kompletnośd strukturalna) określa wszystkie rzeczy, które system ma robid oraz wszystkie rzeczy, których robid nie ma koniecznośd

11 Inżynieria oprogramowania Strona 11 a) b) 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) koniecznośd czy zawiera wszystkie elementy istotne dla zamawiającego czy nie zawiera elementów niepotrzebnych spójnośd czy wymagania zamawiającego są zgodne z wizją i niesprzeczne ze sobą czy nie przeczy sobie jednolicie korzysta z pojęd możliwośd porządkowania (priorytetyzacja) atrybuty umożliwiające określenie wagi i znaczenia weryfikowalnośd czy każde wymaganie ma przyporządkowane kryterium jakości istnieje procedura pozwalająca przetestowanie każdego z wymagao każde wymaganie jest opisane deklaratywnie modyfikowalnośd czy można w łatwy sposób wprowadzad zmiany do specyfikacji wymagao dobrze zorganizowana minimalna redundancja możliwośd śledzenia coupling factor współczynnik zależności pomiędzy modułami utrzymywanie śladu zachowywanie zależności z wcześniej otrzymanymi fragmentami dokumentacji specyfikacja wynika z przypadków użycia Jeden system różne perspektywy struktura 1) model logiczny 2) kod wynikowy 3) warstwa fizyczna zachowanie 1) przypadki użycia 2) algorytmy działania 3) interakcje między obiektami 4) maszyny stanowe rozłączne tworzenie specyfikacji i projektu pozwala na późniejszą weryfikację całości Co jest najważniejsze dla sukcesu projektu? Wiarygodne oszacowanie Jasne cele biznesowe Doświadczony menedżer Wykwalifikowany zespół Zaangażowanie użytkowników Stałe ograniczenie zakresu Formalna metodyka Zaangażowanie użytkowników Elastyczne podejście do wymagao Standardowa architektura model trójwarstwowy: model warstwa składowania widok warstwa prezentacji kontroler logika systemu Abstrakcja i dekompozycja abstrakcja upraszcza problem analogie ukrywanie szczegółów nie rozwiązuje problemu dekompozyjca podproblemu podobnej wielkości podproblemy można rozwiązywad niezależnie

12 Inżynieria oprogramowania Strona 12 podproblemu podobnej wielkości podproblemy można rozwiązywad niezależnie ze składania rozwiązao podproblemów otrzymuje się rozwiązanie problemu Zalety można przypisad podzadania różnym osobom podzadania można rozwiązywad równolegle łatwo utrzymywad system w przyszłości można ukryd nieistotne szczegóły Wady scalanie podrozwiązao może stanowid problem problem źle zrozumiany nie da się dobrze zdekomponowad ukrywanie szczegółów nie rozwiązuje problemu Perspektywy UML diagram pakietów diagram klas i diagram obiektów diagram struktur złożonych diagram komponentów diagram wdrożenia diagram przypadków uzycia diagram czynności diagram maszyny stanowej diagramy interakcji (sekwencji, komunikacji, przeglądu interakcji) diagram uwarunkowao czasowych

13 Inżynieria oprogramowania Strona 13

14 Przypadki użycia Inżynieria oprogramowania Strona 14

15 Inżynieria oprogramowania Strona 15 Przypadki użycia Model dziedzinowy / klas / interfejsów / danych

16 Inżynieria oprogramowania Strona 16 UML definiuje 4 poziomy widoczności cech i metod + publiczny element jest widoczny z każdego miejsca w systemie # chroniony element jest widoczny we własnej klasie i jej podklasach prywatny element jest widoczny tylko we własnej klasie ~ publiczny wewnątrz pakietu element jest widoczny tylko wewnątrz własnego pakietu Maszyna stanowa

17 Inżynieria oprogramowania Strona 17 Maszyna stanowa Interakcje

18 Aktywnośd Inżynieria oprogramowania Strona 18

19 Komponenty, wdrożenie Inżynieria oprogramowania Strona 19

20 Warstwy Inżynieria oprogramowania Strona 20

21 Inżynieria oprogramowania Strona 21

22 Inżynieria oprogramowania Strona 22 Architektury 19 marca :33 1) 2) 3) 1) 2) 3) 4) 5) 6) MTBF Mean Time Between Failures Edgar Dijkstra how software is partitioned and structured is important not merely simply programming a correct solution Fred Brooks System Architecture by the architecture of the system I mean the complete and detailed specification of the user interface the architect of a system, like the architect of a building, is the user s agent David Parnas information hiding as the basis of decomposition for ease of maintenance and reuse the separation of interface from implementation of components observations on the separate character of different program elements the uses relationship for controlling the connectivity between components principles for the detection and handling of errors, i.e. exceptions identifying commonalities in families of systems to provide coarsegrained, stable common structures recognition that structure influences nonfunctional qualities of a system Przetwarzanie potokowe (pipe and filter) kolekcja programów ułożona w łaocuch przykład: Latex Klient serwer logika i większośd obliczeo jest realizowana u klienta przykład: gry sieciowe, Outlook Peer to Peer sied zestawiana adhoc Architektura trójwarstwowa (3 tier) warstwa danych warstwa logiki warstwa prezentacji Architektura wielowarstwowa (n tier) prezentacja a. okienka UI b. HTML, XML, JSP, Javascript aplikacja a. workflow, stan sesji, zmiana stron / okien b. obsługuje żądania warstwy prezentacji dziedzina (biznes, usługi biznesowe, model) a. obsługuje zadania warstwy aplikacji b. usługi dziedziny (Kasa, Magazyn) c. może byd wykorzystywana przez kilka aplikacji infrastruktura biznesowa (niskopoziomowe usługi biznesowe) a. niskopoziomowe usługi biznesowe wykorzystywane w wielu dziedzinach usługi techniczne a. bezpieczeostwo, utrwalanie b. wysokopoziomowe usługi techniczne podstawy a. struktury danych, obsługa wątków b. niskopoziomowe usługi techniczne Perspektywa historyczna

23 Inżynieria oprogramowania Strona 23 Perspektywa historyczna Sevice oriented architecture functionality ważniejsze od connectivity ery architektury 1) mainframe 2) klient serwer 3) Web 4) SOA osiągamy przełom technologiczny pomiędzy mocą obliczeniową a możliwością łączności SOA składanie usług zaawansowanych z rozproszonych usług sieciowych Usługa usługi tworzą rozróżnialne poprzez standaryzację klasy abstrakcji katalogi dobrze zdefiniowane samowystarczalne zawsze i łatwo dostępne niezależne od kontekstu konsumenta nie jest istotne, kto jest klientem bardzo konkurencyjne konkurowanie zakresem a nie sposobem implementacji można łączyd EDI elektroniczny obieg dokumentów BPM business process managing (procesy biznesowe) WS web services Workflow obieg informacji, obieg zadao podobne klocki składa się w nowe narzędzia Aktorzy konsument wyraża zamiar dostawca udostępnia ofertę broker znajduje najlepszą ofertę reklamuje oferty na różne sposoby

24 Inżynieria oprogramowania Strona 24 znajduje najlepszą ofertę reklamuje oferty na różne sposoby odpowiadające różnym zamiarom zapewnia usługę katalogową ("yellow pages") podejście dawne wywalamy istniejące systemy i budujemy jeden super system podejście współczesne tworzymy rejestr usług na bazie istniejących systemów aplikacje klienckie odwołują się do rejestru usług, a dopiero później do konkretnych systemów poprzez XML'a autentykacja ustalenie tożsamości autoryzacja ustalenie praw dostępu SOAP simple object acces protocol protokół zdalnego wywoływania objektów dawne rozwiązanie WS* web services* aktualne rozwiązanie służące się do łączenia z web servisami MVC SOA vs Komunikaty usługami sterują komunikaty ważna jest treśd komunikatu, a nie warstwy transportowe różne struktury komunikatów pytanie, czy dopuszczamy utratę komunikatów: komunikaty idempotentne (kilkukrotne wywołanie nie skutkuje niczym negatywnym) komunikacja niezawodna SOA vs Web Services otwarty standard oferowanych usług możliwośd wymiany dokumentów strukturalnych różne zestawy informacji metadane luźne powiązania niewielkie nakłady na konsumpcję usługi przyjmowanie komunikatów nie w pełni rozumianych XML, WSDL późnie wiązanie lokalizacja niezależna od mechanizmu wywołania + katalogi usług możliwe interakcje peertopeer request / response niewydajny i ograniczający model interakcji wzrost poziomu gradualności zacierają się granice między klientem a serwerem SOA vs ESB kręgosłup SOA działa jak broker komunikatów

25 Inżynieria oprogramowania Strona 25 działa jak broker komunikatów zapewnia system kolejkowania komunikatów MQ message queue proste kolejkowanie MB message brocker potrafi również zarządzad komunikatami potrafi zmieniad format komunikatów, tłumaczyd jedne na drugie standard przemysłowy wymiany komunikatów np. SOA lub JMS zapewnia współpracę aplikacji wysokopoziomowych z niskopoziomowymi poprzez standardowe adaptery i interfejsy dawniej architektura spagetti, teraz szyny Otwarty standard oferowania usług Możliwośd wymiany dokumentów strukturalnych Różny zestaw informacji, metadane (informacje o informacji) Luźne powiązanie Niewielkie nakłady na konsumpcję usługi Przyjmowanie komunikatów nie w pełni rozumianych XML, WSDL Późne wiązanie Lokalizacja niezależna od mechanizmu wołania + katalogi usług Możliwe interakcje peertopeer Request / response Niewydajny i ograniczający model interakcji Wzrost poziomu granularności Zacierają się granice między klientem a serwerem SOA vs BPM BPM bussines process modeling SOA konstruowanie komponentów oprogramowania komponenty mogą byd reużuywane w nieznanym w momencie projketowania kontekście kompozycja vs rozszerzanie (OO) BPM zdolnośd do precyzyjnego modelowania zmiany kontekstu w którym komponenty (przedsiębiorstwa) są wykorzystywane Przejście na architekturę zorientowaną usługowo

26 Inżynieria oprogramowania Strona 26 Przejście na architekturę zorientowaną usługowo Dotarcie do SOA Osiągnięcie przez organizację kontroli nad zasobami IT Zorganizowanie logiki biznesowej w sposób niezależny od kontekstu jej wykorzystania Ponowna implementacja warstwy kontrolera Wykorzystanie technologii koordynacji Orkiestracja Choreografia Stworzenie nowej warstwy widoku Problemy Wymagane dobre rozumienie własnego biznesu Jest to inwestycja (usług >= procesów) Może byd dużym narzutem dla małych przedsiębiorstw Kiedy nie warto wdrażad SOA? Stabilne, homogeniczne środowiska IT SOA może nie byd istotne SOA może byd nieefektywne kosztowo Organizacja nie oferuje i nie wykorzystuje usług opartych na IT Nie ma potrzeby zapewnienia elastyczności Systemy czasu rzeczywistego SOA bazuje na luźno powiązanej komunikacji asynchronicznej Podsumowanie zorientowanie na usługi to nowy paradygmat obliczeniowy koncepcja konstrukcji oprogramowania SOA wymusza postrzeganie oprogramowania przez pryzmat: Większej ilości konsumentów Nieznanego kontekstu SOA jest ciągle przed nami: ewolucja, nie rewolucja Podnosi poziom abstrakcji i reużywalnośd systemów IT Możemy oczekiwad trendu do posiadania i publikowania usług Już się zaznacza (np. Google) Dotknie szczególnie aplikacji Mainframe i Klient/Serwer (ERP, CRM, ) Oprogramowanie będzie bogatsze i sprytniejsze Może stad się koszmarem, jeśli uwzględnimy ryzyka bezpieczeostwa Nie wszystkie technologie są dojrzałe Potrzeba zapewnienia zbieżności standardów

27 Inżynieria oprogramowania Strona 27

28 Inżynieria oprogramowania Strona 28 Jakośd 9 kwietnia :40 zestrzelenie Airbusa śmierd pacjentów chorych na raka, pentium floating point, 1994 rakieta Ariane 5, 1996 Czym jest jakośd? jak można zmierzyd jakośd mierzenie jakości w trakcie produkcji związek jakości produktu z jakością procesu wytwórczego jak można porównywad jakośd poszczególnych dostawców normy i standardy jakości dojrzałośd firm wytwarzających oprogramowanie w USA najbardziej zainteresowane jakością jest wojsko mierzenie jakości krzesła jakośd konstrukcji wartośd estetyczna zgodnośd z oczekiwaniami wszystkie miary jakości są względne jeśli nawet uda się ustalid, co jest lepsze, to i tak ciężko stwierdzid, o ile lepsze mierzenie jakości oprogramowania jakośd konstrukcji oprogramowanie nie powstaje w procesie manufaktury wartości estetyczne zdecydowana większośd napisanego oprogramowania jest niewidoczna wartośd estetyczna ma znaczenie w przypadku interfejsu użytkownika, ale jest to element marginalny z punktu widzenia jakości zgodnośd z oczekiwaniami wymagałoby prawdziwego zrozumienia przeznaczenia systemu Klasyczne podejście oprogramowanie jest dobrej jakości jeśli jest dopasowane do potrzeb robi to, co trzeba da się je rozszerzad działa niezawodnie działa szybko jest bezpieczne jest ergonomiczne jest w odpowiedniej cenie Jakośd trzeba mierzyd potrzeba zamienienia nieprecyzyjnych pomysłów w konkretne miary koncepcje jakości pojęcia abstrakcyjne pojęcia mierzalne definicje metryk co mierzyd pobranie pomiarów realizacja metryk jak mierzyd?

29 Inżynieria oprogramowania Strona 29 jak mierzyd? reliability mean time to failure? run it and count crashes per hour complexity information flow between modules? count procedure calls usability time taken to leran how to use? minutes taken for some user task? Cztery najważniejsze elementy? niezawodnośd projektant musi przewidzied jak się system zachowa kompletnośd czy robi wszystko co trzeba? czy obsługuje wszystkie dane wejściowe? spójnośd czy zawsze zachowuje się zgodnie z oczekiwaniami? odpornośd czy dobrze zachowuje się w warunkach niestandardowych? wydajnośd wykorzystanie zasobów takich jak czas procesora, pamięd, przepustowośd sieci w większości przypadków jest to mniej istotne niż niezawodnośd pielęgnowalnośd jak łatwo można będzie w przyszłości modyfikowad oprogramowanie? działania doskonalące, adaptujące, naprawcze użytecznośd jak łatwe jest w użyciu Jakośd jakośd trzeba przewidywad jakośd jest miarą relacji pomiędzy oprogramowaniem a dziedziną zastosowao może nie da się mierzyd jakości przed ostatecznym uruchomieniem systemu jakośd może się różnid zależnie od środowiska podczas projektowania musi byd możliwe przewidywanie jakości należy rozumied potrzeby (inżynieria wymagao) należy szukad wyznaczników jakości Generalnie dwa najważniejsze elementy kontrola jakości zapewnianie jakości dodatkowo mała i duża skala projektu Kontrola jakości walidacja czy budujemy właściwy system subiektywne trudno to stwierdzid zestaw przypadków testowych (najlepiej jak najwcześniej zdefiniowanych) weryfikacja czy budujemy system prawidłowo

30 Inżynieria oprogramowania Strona 30 czy budujemy system prawidłowo może byd obiektywne techniki kontroli jakości porównywanie oprogramowania ze specyfikacją weryfikacja (jeśli specyfikacja jest techniczna, to byd może da się to zrobid automatycznie) porównanie oprogramowania ze światem walidacja Przypadek testowy pochodna przypadku użycia prawie jeden do jednego względem scenariuszy w przypadkach testowych scenariusze testowe pochodne przypadków biznesowych trzeba byd w stanie śledzid zależności pomiędzy przypadkami użycia, procesami biznesowymi i przypadkami testowymi konieczne jest opisanie stanu systemu Walidacja czy system realizuje to, co trzeba? świat> analiza > projekt > system subiektywne Weryfikacja czy oprogramowanie jest zgodne ze specyfikacją może byd obiektywne zależy od jakości specyfikacji walidacja i weryfikacja muszą byd wykonywane przez cały czas realizacji projektu cele: wykrycie błędów w systemie sprawdzanie, czy system się do czegoś nadaje Trzy sposoby kontroli testowanie system jest uruchamiany z danymi testowymi inspekcje (review) analiza statycznej reprezentacji systemu w celu wykrycia problemów metody formalne Testowanie kto ma testowad jak testowad co poddawad testom nietestowanie może mied sens gdy kary za opóźnienie są o wiele większe od kar za błędy gdy system ma byd odpalony tylko raz decyzję na temat jakości należy podjąd na samym początku losowe testy nie wystarczą Podejście systematyczne systematyczne testowanie opera sie na partycjonowanmiu podziel zachowania systemu na grupy dla każdej grupy wybierz reprezentatywne próbki upewnij się, że uwzględniono wszystkie grupy jak zidentyfikowad dobry podział?

31 Inżynieria oprogramowania Strona 31 jak zidentyfikowad dobry podział? metody wyboru przypadków testowych czarna skrzynka (black box) przezroczysta skrzynka (white box) Przypadek testowy dane wejściowe stan wstępny zaobserwowane wyjście migawki maszyny wirtualnej zrzuty bazy danych i plików konfiguracyjnych skrypty zapełniające / czyszczące dane programu istnieją narzędzia półautomatyczne Czarna skrzynka generowane na podstawie specyfikacji nie patrzymy na kod programu zalety: unikanie przyjmowania tych samych założeo, co programista dane testowe są niezależne od implementacji wyniki można interpretowad bez wnikania w szczegóły systemy sugestie wyboru przypadków ścieżki specyfikacji pokrywają klauzule "wymaga, modyfikuje, wpływa na" warunki brzegowe Szukaj błędów w aliasach (dwa parametry odnoszące się do tego samego obiektu) przypadki nienormalne niepoprawne dane wejściowe Przezroczysta skrzynka badanie kodu i testowanie ścieżek w kodzie czarna skrzynka może nie spowodowad wykonania całego kodu kompletnośd instrukcji zestaw testów pokrywa komplet instrukcji jeśli każda instrukcja w kodzie jest wykonywana co najmniej raz w zestawie testów kompletnośd ścieżek zestaw testów pokrywa komplet ścieżek, jeśli każda ścieżka w kodzie jest wykonywana co najmniej raz w zestawie testów Pokrycie pokrycie instrukcji (statement coverage) pokrycie gałęzi instrukcja warunkowa musi byd przynajmniej raz prawdziwa i przynajmniej raz fałszywa Atrybuty procesu testowania powtarzalne systematyczne trzeba wybierad zestawy testów pokrywające cały zakres działania programu należy wybierad testy które są reprezentatywne dla rzeczywistych zastosowao dokumentowane Testy jednostkowe pisz test, nim napiszesz moduł przypadek użycia > przypadek testowy każda jednostka / moduł testowany jest oddzielnie

32 Inżynieria oprogramowania Strona 32 każda jednostka / moduł testowany jest oddzielnie czy spełnia specyfikację nie ma modułu bez testu extreme programming Testy integracji czy moduły współpracują ze sobą podejścia: bottom up (po odwróconym grafie) top down (stubs) coupling factor współczynnik powiązao pomiędzy systemami chcemy go minimalizowad na tym polega architektura komponentowa często wykrywają błędy specyfikacji a nie błędy integracji Testy systemowe na poziomie całej aplikacji testowanie funkcjonalności Testy pozafunkcjonalne facility testing Czy system zapewnia wszystkie wymagane funkcje? volume testing Czy system radzi sobie z dużą ilością danych? stress testing Czy system radzi sobie z dużym obciążeniem? endurance testing Czy system zachowuje parametry w długim okresie? usability testing Czy system jest łatwy w użyciu? security testing Czy system wytrzymuje ataki? performance testing Jak dobry jest czas reakcji systemu? storage testing Czy pojawiają się problemy ze składowaniem danych? configuration testing Czy system działa na wszystkich platformach? installability testing Czy da się skutecznie zainstalowad system? reliability testing Jak zmienia się niezawodnośd systemu w czasie? recovery testing Jak skutecznie system podnosi się po awarii? serviceability testing Czy daje się pielęgnowad system? documentation testing Czy dokumentacja jest dokładna? Adekwatna? operations testing Czy instrukcje operatorów są poprawne? Test regresji ponowne wykonanie opracowanych wcześniej testów Test uruchomieniowy (smoke test) czy program się uruchamia wersja minimalna testowania regresywnego JUnit testy jednostkowe Testowanie a debugowanie testowanie koncentruje się na znajdowaniu błędów debugowanie zajmuje się lokalizacją i usuwaniem błędów Inspekcje znaczenie zmniejszają liczbę błędów poprawianie kodu podczas inspekcji jest taosze, niż podczas debugowania lub już po wydaniu koszty naprawy danych są bardzo wysokie wpływ na morale zespołu, mniejsza rotacja lepsze rozpoznanie możliwości zespołu

33 Inżynieria oprogramowania Strona 33 Ograniczenia inspekcji dobry zespół max 6 osób min 3, max 7 osób podczas inspekcji czas max 2 godziny (spada koncentracja) wyniki wszyscy muszą się zgadzad podsumowanie (raport szczegółowa lista zagadnieo) skupiamy się na małym fragmencie 150 LOC / h harmonogram nie za wcześnie autor świadom błędów nie za późni nic to już nie da przegląd po zakooczeniu prac autora Wytyczne inspekcji przed spotkaniem należy jasno zdefiniowad cel i oczekiwane efekty niezbędny lider fakt inspekcji należy zapisad uczestnicy powinni móc przygotowad się do inspekcji

34 Inżynieria oprogramowania Strona 34 Zarządzanie konfiguracją 23 kwietnia :56 opisuje zależności pomiędzy różnymi komponentami gałęzie przy zarządzaniu wersjami bazowa przed wydaniem dla zadao można zdad się na integratorów zarządzanie konfiguracją kontrola wersji zarządzanie zmianą budowanie wydao zmiany w makefile'u wprowadza tylko jedna osoba sposób na ograniczenie coupling factoru dodanie zależności od kolejnej biblioteki wymaga uzgodnieo co powstaje przy produkcji oprogramowania: Specyfikacja (funkcjonalna, pozafunkcjonalna) Projekt, model Prototyp Kod źródłowy Testy (jednostkowe, użytkownika) Wydania (binaria) Instrukcja instalacji Lista zmian (w stosunku do wydania poprzedniego) Lista znanych błędów Podręczniki (użytkownika, administratora) Harmonogram Notatki robocze zespołu 1) 2) 3) Wyzwania: równoległa praca nad różnymi fragmentami kodu identyfikacja i przechowywanie różnych wersji dokumentów wersje dokumentów a wersje produktów analizowanie histori kto, kiedy, jaka zmiana praca nad nową wersją systemu i poprawianie błędów w starej Zarządzanie konfiguracją kontrola wersji zarządzanie zmianą budowanie wydao Kontrola wersji komunikacja z centralnym systemem kopia lokalna repozytorium i wprowadzanie zmian w centralnym repozytorium na żądanie etykiety gałęzie bazowa przed wydaniem dla zadao

35 Inżynieria oprogramowania Strona 35 Pytania do systemu zarządzania konfiguracją Jaka platforma jest wymagana dla danej wersji systemu? Które wersje systemu są zależne od zmiany danego komponentu? Ile błędów zgłoszono do danej wersji? Jakie komponenty zmodyfikowano przy realizacji danej zmiany? Budowanie wydao dobre praktyki Przyrostowa zmiana systemu jaka może byd włączona do nowego wydania jest w przybliżeniu stałego rozmiaru Jeśli zbyt wiele nowych cech zostanie włączonych razem z poprawkami błędów, wówczas koszt przygotowania nowego wydania znacząco wzrasta Jeśli do wydania włączono wiele zmian, musi nastąpid po nim wydanie poprawiające błędy wynikające ze zmian wprowadzonych w pierwszym wydaniu Plan zarządzania konfiguracja definiuje artefakty podlegających zarządzaniu konfiguracją standardy nazewnictwa role odpowiedzialne za tworzenie linii bazowych procedury kontroli zmian i wersjonowania zasady wglądu klienta w rejestry opisuje narzędzia wspierające zarządzanie konfiguracją system kontroli wersji system śledzenia zmian system budowania wydao konfigurację narzędzi odpowiadającą przyjętej procedurze uprawnienia użytkowników w systemie Narzędzia kontroli wersji Identyfikacja wersji i wydao systemu System przydziela identyfikatory automatycznie podczas zgłaszania nowej wersji pliku do systemu Kontrolowanie zmian Tylko jedna wersja w danej chwili może podlegad zmianie. Można równolegle pracowad nad różnymi wersjami. Zarządzanie przestrzenią dyskową Przechowywanie różnid a nie pełnych nowych wersji Dla danych tekstowych jak też binarnych Rejestrowanie historii zmian Zapamiętuje uzasadnienia wprowadzenia zmian Narzędzia budowania systemu problemy czy uwzględniono wszystkie wymagane komponenty? czy wskazano właściwą wersję komponentu? czy wszystkie pliki z danymi są dostępne? czy odwołania do plików / komponentów są poprawne? czy system jest budowany na właściwą platformę? czy wykorzystywana jest właściwa wersja kompilatora i narzędzi deweloperskich? Narzędzia śledzenia zmian Głównym zadaniem śledzenie statusów zgłoszonych zmian/błędów Automatycznie zapewnia że zmiany są przekierowywane do właściwych osób (np. do właścicieli komponentów, których zmiany dotyczą) Organizuje współpracę w ramach zespołu

36 Inżynieria oprogramowania Strona 36 właścicieli komponentów, których zmiany dotyczą) Organizuje współpracę w ramach zespołu Integracja z pocztą elektroniczną zapewnia powiadamiania i eskalację problemów Zarządzanie zmianą

37 Inżynieria oprogramowania Strona 37 Planowanie 30 kwietnia :39 1) 2) 3) 4) 1) 2) 3) Podstawowe pytania ile potrzeba pracy jaki jest całkowity koszt ile dni kalendarzowych jest potrzebne jaki zespół jest potrzebny Oszacowanie pracochłonności sposoby metryki a. metoda punktów funkcyjnych b. metoda punktów obiektowych ekspertyzy a. struktura podziału pracy b. diagram sieciowy c. zrównoważenie zasobów inne a. szacowanie na podstawie wielkości kodu źródłowego Metoda punktów funkcyjnych bazujemy na opisie funkcjonalności uwzględniamy aspekty technologiczne wybór języka środowiskowe rodzaj zespołu funkcjonalne przypadki użycia aktorzy Aspekt technologiczny Aspekt środowiskowy

38 Inżynieria oprogramowania Strona 38 Przypadki użycia Aktorzy

39 Inżynieria oprogramowania Strona 39 Wynik Struktura podziału pracy (WBS) Work Breakdown Structure definicja zakresu projektu hierarchiczna list czynności drzewo co jest częścią czego tworzona w oparciu o podstawowe techniki abstrakcja dekompozycja jakośd bazuje na jakości ekspertów stopieo szczegółowości (dla każdego liścia) kto jest odpowiedzialny ile czasu potrwa realizacja ile będzie kosztowad?

40 Inżynieria oprogramowania Strona 40 Diagram sieciowy (diagram projektu) co zależy od czego w jakiej kolejności należy budowad jedno źródło, jedno ujście ustalenie logiki ścieżka krytyczna najdłuższa (z wagami) ścieżka od startu do zakooczenia jest to długośd projektu dla każdej czynności najwcześniejsze rozpoczęcia najpóźniejsze zakooczenie wynikiem jest graf zależności jedno źródło i jedno ujście ścieżki w grafie, ścieżka krytyczna niepewnośd oszacowania zapas zadania najpóźniejsze zakooczenie najwcześniejsze zakooczenie czynnośd na ścieżce krytycznej ma zapas zerowy wolny zapas całkowity zapas ścieżka krytyczna najdłuższa (z wagami) ścieżka od źródła do ujścia

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

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

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

Projektowanie oprogramowania

Projektowanie oprogramowania Wrocław, 27.09.2010 1. Warunki wstępne Projektowanie oprogramowania Warunkiem uczestnictwa w zajęciach jest zaliczenie przedmiotu: Podstawy inżynierii oprogramowania (ćwiczenia) Zajęcia składają się z

Bardziej szczegółowo

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie

Bardziej szczegółowo

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2 Modelowanie i analiza systemów informatycznych 1. Warstwowa budowa systemów informatycznych 2. Model procesu wytwarzania oprogramowania - model cyklu życia oprogramowania 3. Wstęp do modelowania systemów

Bardziej szczegółowo

Analityk i współczesna analiza

Analityk i współczesna analiza Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura

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

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

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

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,

Bardziej szczegółowo

Zasady organizacji projektów informatycznych

Zasady organizacji projektów informatycznych Zasady organizacji projektów informatycznych Systemy informatyczne w zarządzaniu dr hab. inż. Joanna Józefowska, prof. PP Plan Definicja projektu informatycznego Fazy realizacji projektów informatycznych

Bardziej szczegółowo

Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC

Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC Akademia MetaPack Uniwersytet Zielonogórski Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC Krzysztof Blacha Microsoft Certified Professional Budowa aplikacji ASP.NET z wykorzystaniem wzorca MVC Agenda:

Bardziej szczegółowo

Modelowanie i Programowanie Obiektowe

Modelowanie i Programowanie Obiektowe Modelowanie i Programowanie Obiektowe Wykład I: Wstęp 20 październik 2012 Programowanie obiektowe Metodyka wytwarzania oprogramowania Metodyka Metodyka ustandaryzowane dla wybranego obszaru podejście do

Bardziej szczegółowo

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia)

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne

Bardziej szczegółowo

Inżynierski Projekt Zespołowy

Inżynierski Projekt Zespołowy Inżynierski Projekt Zespołowy Projekt Funkcji Systemu 1. Wymagania funkcjonalne i niefunkcjonalne Prace nad specyfikacją powinny się koncentrowad na funkcjonalnościach, interakcji systemu z użytkownikiem,

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 1 Inżynieria Oprogramowania

Wykład 1 Inżynieria Oprogramowania Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI

Bardziej szczegółowo

Informatyzacja przedsiębiorstw WYKŁAD

Informatyzacja przedsiębiorstw WYKŁAD Informatyzacja przedsiębiorstw WYKŁAD dr inż. Piotr Zabawa IBM/Rational Certified Consultant pzabawa@pk.edu.pl wersja 0.1.0 07.10.2010 Wykład 1 Modelowanie procesów biznesowych Przypomnienie rodzajów narzędzi

Bardziej szczegółowo

Zarządzanie Projektami zgodnie z PRINCE2

Zarządzanie Projektami zgodnie z PRINCE2 Zarządzanie Projektami zgodnie z PRINCE2 Opis Metodyka PRINCE2 powstała na bazie doświadczeń z wielu lat dobrych praktyk zarządzania projektami. Metodyka ta oferuje elastyczne i łatwe do adaptacji podejście

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

Spis treúci. 1. Wprowadzenie... 13

Spis treúci. 1. Wprowadzenie... 13 Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...

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

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

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

Procesowa specyfikacja systemów IT

Procesowa specyfikacja systemów IT Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia)

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia) Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów dziennych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne przedmioty.

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

Zapewnij sukces swym projektom

Zapewnij sukces swym projektom Zapewnij sukces swym projektom HumanWork PROJECT to aplikacja dla zespołów projektowych, które chcą poprawić swą komunikację, uprościć procesy podejmowania decyzji oraz kończyć projekty na czas i zgodnie

Bardziej szczegółowo

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław

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

Dr Katarzyna Grzesiak-Koped

Dr Katarzyna Grzesiak-Koped Dr Katarzyna Grzesiak-Koped 2 Tworzenie oprogramowania Najlepsze praktyki IO Inżynieria wymagao Technologia obiektowa i język UML Techniki IO Metodyki zwinne Refaktoryzacja Mierzenie oprogramowania Jakośd

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

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus Automatyzacja procesów biznesowych Andrzej Sobecki ESB Enterprise service bus Plan prezentacji Zdefiniowanie problemu Możliwe rozwiązania Cechy ESB JBI Normalizacja wiadomości w JBI Agile ESB Apache ServiceMix

Bardziej szczegółowo

Rozwiązanie Compuware dynatrace

Rozwiązanie Compuware dynatrace Rozwiązanie Compuware dynatrace COMPUWARE DYNATRACE... 3 2 COMPUWARE DYNATRACE Narzędzie Compuware dynatrace oparte jest o unikatową technologię agentową, która pozwala na dogłębną analizę stanu aplikacji

Bardziej szczegółowo

IO - Plan testów. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

IO - Plan testów. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006 IO - Plan testów M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 SPIS TREŚCI 2 Spis treści 1 Historia zmian 3 2 Zakres testów 3 2.1 Integration testing - Testy spójnosci.............. 3 2.2

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

DLA SEKTORA INFORMATYCZNEGO W POLSCE

DLA SEKTORA INFORMATYCZNEGO W POLSCE DLA SEKTORA INFORMATYCZNEGO W POLSCE SRK IT obejmuje kompetencje najważniejsze i specyficzne dla samego IT są: programowanie i zarządzanie systemami informatycznymi. Z rozwiązań IT korzysta się w każdej

Bardziej szczegółowo

UML w Visual Studio. Michał Ciećwierz

UML w Visual Studio. Michał Ciećwierz UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować

Bardziej szczegółowo

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy

Bardziej szczegółowo

Większe możliwości dzięki LabVIEW 2009: programowanie równoległe, technologie bezprzewodowe i funkcje matematyczne w systemach czasu rzeczywistego

Większe możliwości dzięki LabVIEW 2009: programowanie równoległe, technologie bezprzewodowe i funkcje matematyczne w systemach czasu rzeczywistego Większe możliwości dzięki LabVIEW 2009: programowanie równoległe, technologie bezprzewodowe i funkcje matematyczne w systemach czasu rzeczywistego Dziś bardziej niż kiedykolwiek narzędzia używane przez

Bardziej szczegółowo

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych

Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Skrócone opisy pryncypiów architektury korporacyjnej podmiotów publicznych Wersja: 1.0 17.06.2015 r. Wstęp W dokumencie przedstawiono skróconą wersję pryncypiów architektury korporacyjnej podmiotów publicznych.

Bardziej szczegółowo

SOA Web Services in Java

SOA Web Services in Java Wydział Informatyki i Zarządzania Wrocław,16 marca 2009 Plan prezentacji SOA 1 SOA 2 Usługi Przykłady Jak zacząć SOA Wycinek rzeczywistości Problemy zintegrowanych serwisów : Wycinek Rzeczywistości Zacznijmy

Bardziej szczegółowo

Zarządzanie testowaniem wspierane narzędziem HP Quality Center

Zarządzanie testowaniem wspierane narzędziem HP Quality Center Zarządzanie testowaniem wspierane narzędziem HP Quality Center studium przypadku Mirek Piotr Szydłowski Ślęzak Warszawa, 17.05.2011 2008.09.25 WWW.CORRSE.COM Firma CORRSE Nasze zainteresowania zawodowe

Bardziej szczegółowo

Projektowanie Modeli Usług dla rozwiązań typu SOA

Projektowanie Modeli Usług dla rozwiązań typu SOA Projektowanie Modeli Usług dla rozwiązań typu SOA Service Oriented Modeling and Architecture (SOMA ) IBM Global Business Services, zdefiniował zestaw usług konsultingowych oraz narzędzi pomagających organizacjom

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

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych

Bardziej szczegółowo

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 5 Definicja systemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use

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

Tester oprogramowania 2014/15 Tematy prac dyplomowych

Tester oprogramowania 2014/15 Tematy prac dyplomowych Tester oprogramowania 2014/15 Tematy prac dyplomowych 1. Projekt i wykonanie automatycznych testów funkcjonalnych wg filozofii BDD za pomocą dowolnego narzędzia Jak w praktyce stosować Behaviour Driven

Bardziej szczegółowo

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia

Inżynieria oprogramowania. Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia Inżynieria oprogramowania Wykład 7 Inżynieria wymagań: punkty widzenia, scenariusze, przypadki użycia Punkt widzenia (Point of View) Systemy oprogramowania mają zwykle kilku różnych użytkowników. Wielu

Bardziej szczegółowo

ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A.

ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A. ZAŁĄCZNIK Nr 2 do CZĘŚCI II SIWZ WYCIĄG ZE STANDARDÓW, ZASAD I WZORCÓW INTEGRACYJNYCH OBOWIĄZUJĄCYCH W PSE S.A. 1 Załącznik Nr 2 do Część II SIWZ Wyciąg ze standardów, zasad i wzorców integracyjnych obowiązujących

Bardziej szczegółowo

III Etap konkursu TWOJA FIRMA TWOJA SZANSA NA SUKCES

III Etap konkursu TWOJA FIRMA TWOJA SZANSA NA SUKCES PROTECT DNA OF YOUR BUSINESS BUSINESS CONTINUITY INCIDENT AND RISK MANAGEMENT REAL TIME ENTERPRISE III Etap konkursu TWOJA FIRMA TWOJA SZANSA NA SUKCES Warszawa 11.05.2011 Projekt współfinansowany przez

Bardziej szczegółowo

Szczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Szczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych Szczególne problemy projektowania aplikacji Jarosław Kuchta Miejsce projektowania w cyklu wytwarzania aplikacji SWS Analiza systemowa Analiza statyczna Analiza funkcjonalna Analiza dynamiczna Analiza behawioralna

Bardziej szczegółowo

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych PAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W ELBLĄGU INSTYTUT INFORMATYKI STOSOWANEJ Sprawozdanie z Seminarium Dyplomowego Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Bardziej szczegółowo

Testowanie oprogramowania w środowisku IBM Rational Software Architect

Testowanie oprogramowania w środowisku IBM Rational Software Architect Testowanie oprogramowania w środowisku IBM Rational Software Architect Software Development 2008 Michał Wolski m.wolski@modesto.pl szkolenia: inżynierii oprogramowania zarządzania projektami usługi doradcze

Bardziej szczegółowo

Aurea BPM Dokumenty pod kontrolą

Aurea BPM Dokumenty pod kontrolą Aurea BPM Dokumenty pod kontrolą 1 Aurea BPM unikalna platforma o wyróżniających cechach Quality Software Solutions Aurea BPM Aurea BPM system informatyczny wspomagający zarządzanie procesami biznesowymi

Bardziej szczegółowo

System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa?

System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa? System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa? Koszalin, 15-16.05.2006 III Zawodowa Konferencja Zawód kartografa 200910151500 Agenda 1. Koncepcja SKBDT 2. Podstawowe założenia koncepcji

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

Testowanie według modelu (MBT) Stowarzyszenie Inżynierii Wymagań wymagania.org.pl

Testowanie według modelu (MBT) Stowarzyszenie Inżynierii Wymagań wymagania.org.pl Testowanie według modelu (MBT) Bogdan Bereza, Victo MBT testowanie z modelu wersja 2.1 A 1 (48) Pozdrawiam Best regards Med vänliga hälsningar Bogdan Bereza bogdan.bereza@victo.eu +48 519 152 106 Skype:

Bardziej szczegółowo

Spis treści. Dzień 1. I Wprowadzenie (wersja 0906) II Dostęp do danych bieżących specyfikacja OPC Data Access (wersja 0906) Kurs OPC S7

Spis treści. Dzień 1. I Wprowadzenie (wersja 0906) II Dostęp do danych bieżących specyfikacja OPC Data Access (wersja 0906) Kurs OPC S7 I Wprowadzenie (wersja 0906) Kurs OPC S7 Spis treści Dzień 1 I-3 O czym będziemy mówić? I-4 Typowe sytuacje I-5 Klasyczne podejście do komunikacji z urządzeniami automatyki I-6 Cechy podejścia dedykowanego

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

Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia. Click Piotr Kałuski to edit Master subtitle style

Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia. Click Piotr Kałuski to edit Master subtitle style Jak patrzymy na testy czyli Jak punkt widzenia zależy od punktu siedzenia Click Piotr Kałuski to edit Master subtitle style Punkty widzenia Zespół Testów Manager Projektu Użytkownik końcowy Zespół Testów

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

Oracle Designer. Oracle Designer jest jednym z głównych komponentów pakietu Oracle Developer Suite. Oracle Designer wspiera :

Oracle Designer. Oracle Designer jest jednym z głównych komponentów pakietu Oracle Developer Suite. Oracle Designer wspiera : Oracle Designer Oracle Designer jest jednym z głównych komponentów pakietu Oracle Developer Suite. Oracle Designer wspiera : - modelowanie procesów biznesowych - analizę systemu informatycznego - projektowanie

Bardziej szczegółowo

JBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE]

JBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE] JBPM [JUG] Tomasz Gratkowski [GRATKOWSKI SOFTWARE] Parę słów o mnie 2 Nauczyciel akademicki od 2000 roku Od 2002 współpracuję z firmami jako programista i projektant aplikacji Od 2006 roku właściciel firmy

Bardziej szczegółowo

Warstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe.

Warstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. Warstwa integracji wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. 1. Ukrycie logiki dostępu do danych w osobnej warstwie 2. Oddzielenie mechanizmów trwałości od modelu obiektowego Pięciowarstwowy

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

Jarosław Żeliński analityk biznesowy, projektant systemów

Jarosław Żeliński analityk biznesowy, projektant systemów Modele wdrażania i zarządzania projektami ERP Jarosław Żeliński analityk biznesowy, projektant systemów (c) Jarosław Żeliński IT-Consulting 1 Cel prezentacji Wskazanie kluczowych ryzyk projektów wdrożenia

Bardziej szczegółowo

Prezentacja firmy Royal Solutions Sp. z o.o.

Prezentacja firmy Royal Solutions Sp. z o.o. Prezentacja firmy Royal Solutions Sp. z o.o. Zawartość prezentacji Misja Doświadczenie Konsultanci Technologie Podejście do Klienta Proces realizacji projektów Badania dojrzałości projektowej Projekty

Bardziej szczegółowo

REKOMENDACJE DOTYCZĄCE PLATFORMY ZARZĄDZANIA KOMPETENCJAMI

REKOMENDACJE DOTYCZĄCE PLATFORMY ZARZĄDZANIA KOMPETENCJAMI REKOMENDACJE DOTYCZĄCE PLATFORMY ZARZĄDZANIA KOMPETENCJAMI WYTYCZNE DO MODELU DANIEL WOJEWÓDZKI Rekomendacje dotyczące Platformy Zarządzania Kompetencjami System adresowany do małych przedsiębiorstw do

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

Architektura bezpieczeństwa informacji w ochronie zdrowia. Warszawa, 29 listopada 2011

Architektura bezpieczeństwa informacji w ochronie zdrowia. Warszawa, 29 listopada 2011 Architektura informacji w ochronie zdrowia Warszawa, 29 listopada 2011 Potrzeba Pomiędzy 17 a 19 kwietnia 2011 roku zostały wykradzione dane z 77 milionów kont Sony PlayStation Network. 2 tygodnie 25 milionów

Bardziej szczegółowo

Projektowanie interakcji

Projektowanie interakcji Projektowanie interakcji K2 User Experience www.k2.pl/ux Tytuł dokumentu: k2-projektowanie_ux-oferta.pdf Data: 21 sierpnia 2009 Przygotowany przez: Maciej Lipiec Maciej Lipiec User Experience Director

Bardziej szczegółowo

Platforma Informatyczna Wdrażania Oprogramowania Dedykowanego w PL-Grid

Platforma Informatyczna Wdrażania Oprogramowania Dedykowanego w PL-Grid 1 Platforma Informatyczna Wdrażania Oprogramowania Dedykowanego w PL-Grid Grzegorz Banach Wrocławskie Centrum Sieciowo-Superkomputerowe, Politechnika Wrocławska, Instytut Niskich Temperatur i Badań Strukturalnych

Bardziej szczegółowo

udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu baz danych

udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu baz danych Rola architektury systemów IT Wymagania udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu metod modelowania architektury systemów IT - UML, systemów zorientowanych na usługi, systemów

Bardziej szczegółowo

Innowacje w IT czyli dlaczego to takie trudne? Jakub Dąbkowski

Innowacje w IT czyli dlaczego to takie trudne? Jakub Dąbkowski 2011 Innowacje w IT czyli dlaczego to takie trudne? Jakub Dąbkowski Projekt Projekt - to zbiór aktywności charakteryzujący się następującymi cechami: są ze sobą powiązane w złożony sposób, zmierzają do

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

Instalacja SQL Server Express. Logowanie na stronie Microsoftu

Instalacja SQL Server Express. Logowanie na stronie Microsoftu Instalacja SQL Server Express Logowanie na stronie Microsoftu Wybór wersji do pobrania Pobieranie startuje, przechodzimy do strony z poradami. Wypakowujemy pobrany plik. Otwiera się okno instalacji. Wybieramy

Bardziej szczegółowo

Diagramy klas. WYKŁAD Piotr Ciskowski

Diagramy klas. WYKŁAD Piotr Ciskowski Diagramy klas WYKŁAD Piotr Ciskowski przedstawienie statyki systemu graficzne przedstawienie statycznych, deklaratywnych elementów dziedziny przedmiotowej oraz związków między nimi obiekty byt, egzemplarz

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

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

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP WERSJA 1 z 15 Spis treści 1. Kanał email dla podmiotów zewnętrznych...

Bardziej szczegółowo

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW 01-447 Warszawa ul. Newelska 6, tel. (+48 22) 34-86-520, www.wit.edu.pl Studia podyplomowe BEZPIECZEŃSTWO I JAKOŚĆ SYSTEMÓW INFORMATYCZNYCH PROGRAM NAUCZANIA PLAN STUDIÓW Studia podyplomowe BEZPIECZEŃSTWO

Bardziej szczegółowo

Plan zarządzania projektem

Plan zarządzania projektem Plan zarządzania projektem Opracował: Zatwierdził: Podpis: Podpis: Spis treści: 1. Wst p... 2 1.1 Cel... 2 1.2 Zakres... 2 1.3 Przeznaczenie dokumentu... 2 1.4 Organizacja dokumentu... 2 1.5 Dokumenty

Bardziej szczegółowo

Leszek Dziubiński Damian Joniec Elżbieta Gęborek. Computer Plus Kraków S.A.

Leszek Dziubiński Damian Joniec Elżbieta Gęborek. Computer Plus Kraków S.A. Leszek Dziubiński Damian Joniec Elżbieta Gęborek Computer Plus Kraków S.A. Wykorzystanie Microsoft Project Server w procesie zarządzania projektami Kompetencje partnerskie Gold: Portals and Collaboration

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

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

Narzędzia i aplikacje Java EE. Usługi sieciowe Paweł Czarnul pczarnul@eti.pg.gda.pl

Narzędzia i aplikacje Java EE. Usługi sieciowe Paweł Czarnul pczarnul@eti.pg.gda.pl Narzędzia i aplikacje Java EE Usługi sieciowe Paweł Czarnul pczarnul@eti.pg.gda.pl Niniejsze opracowanie wprowadza w technologię usług sieciowych i implementację usługi na platformie Java EE (JAX-WS) z

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

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

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

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie

Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 6 Wskazówki i sugestie Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 6 Wskazówki i sugestie Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases) Wyzwania podczas pisania przypadków

Bardziej szczegółowo

Ewolucyjna architektura

Ewolucyjna architektura Ewolucyjna architektura www.sxc.hu/photo/850368 Na początek Michał Bartyzel konsultant, trener BNS IT procesy zwinne i nie tylko architektura czysty kod software crafstmanship strategie skutecznych programistów

Bardziej szczegółowo

NAUKOWA I AKADEMICKA SIEĆ KOMPUTEROWA Jak usprawnić pracę w zespole IT? Wykorzystanie narzędzi do pracy grupowej na przykładzie zespołu Polska.pl Agnieszka Kukałowicz-Kolaszyńska, Starszy Specjalista IT

Bardziej szczegółowo

ECDL ZARZĄDZANIE PROJEKTAMI

ECDL ZARZĄDZANIE PROJEKTAMI ECDL ZARZĄDZANIE PROJEKTAMI EUROPEJSKI CERTYFIKAT UMIEJĘTNOŚCI KOMPUTEROWYCH ZARZĄDZANIE PROJEKTAMI Syllabus v. 1.0 Oficjalna wersja dokumentu jest dostępna w serwisie WWW Polskiego Biura ECDL www.ecdl.pl

Bardziej szczegółowo

1 Wprowadzenie do J2EE

1 Wprowadzenie do J2EE Wprowadzenie do J2EE 1 Plan prezentacji 2 Wprowadzenie do Java 2 Enterprise Edition Aplikacje J2EE Serwer aplikacji J2EE Główne cele V Szkoły PLOUG - nowe podejścia do konstrukcji aplikacji J2EE Java 2

Bardziej szczegółowo

Tom 6 Opis oprogramowania

Tom 6 Opis oprogramowania Część 4 Narzędzie do wyliczania wielkości oraz wartości parametrów stanu Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 30 maja 2012 Historia dokumentu Nazwa

Bardziej szczegółowo

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. Usprawnienie procesu zarządzania konfiguracją Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. 1 Typowy model w zarządzaniu IT akceptacja problem problem aktualny stan infrastruktury propozycja

Bardziej szczegółowo

HP Service Anywhere Uproszczenie zarządzania usługami IT

HP Service Anywhere Uproszczenie zarządzania usługami IT HP Service Anywhere Uproszczenie zarządzania usługami IT Robert Nowak Architekt rozwiązań HP Software Dlaczego Software as a Service? Najważniejsze powody za SaaS UZUPEŁNIENIE IT 2 Brak zasobów IT Ograniczone

Bardziej szczegółowo