Skoro taka jest rzeczywistość, to jak można mierzyć jakość oprogramowania lub systemu informatycznego, jak ocenić jakość wykonanego zobowiązania?

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

Download "Skoro taka jest rzeczywistość, to jak można mierzyć jakość oprogramowania lub systemu informatycznego, jak ocenić jakość wykonanego zobowiązania?"

Transkrypt

1 Pojęcie należytej staranności w kontekście analizy wykonania zobowiązań dotyczących oprogramowania komputerowego i wdrażania systemów informatycznych próba definicji Zagadnienie należytej staranności w wykonywaniu zobowiązań ma bardzo bogatą literaturę. Jednakże praktyczne określenie, jaki sposób działania wykonawcy oprogramowania komputerowego lub systemu informatycznego można uznać za wykonanie zobowiązania z dołożeniem należytej staranności, nie jest już takie oczywiste i nie zostało jeszcze opracowane. Ocena jakości wykonania zobowiązań dotyczących oprogramowania komputerowego i wdrażania systemów informatycznych, z jednej strony wydaje się bardzo trudna, z drugiej bardzo prosta. Teoretycznie można przyjąć, że wystarczy przed odbiorem wykonać testy akceptacyjne (User Acceptance Tests - UAT, inaczej zwane Business Acceptance Tests BAT) i jeśli system lub oprogramowanie działa poprawnie to znaczy, że zamawiający otrzymuje dobry produkt odpowiedniej jakości. Dodatkowo należy zbadać dokumentację i sprawdzić, czy wszystkie licencje i inne umowy wynikające z prawa autorskiego, dotyczące ochrony patentów itp. zostały odpowiednio zawarte, a prawa wynikające z tych umów przeniesione na odpowiednie podmioty. Jeśli testy wypadły pomyślnie, a umowy zostały sporządzone prawidłowo możemy przyjąć, że zobowiązanie zostało wykonane należycie. O ile stwierdzenie istnienia lub nieistnienia wad prawnych produktu (na potrzeby niniejszego artykułu będziemy używać pojęcia produkt ), jakim jest oprogramowanie lub system informatyczny, wydaje się w miarę proste i możliwe do przeprowadzenia, o tyle stwierdzenie istnienia lub nie wad fizycznych oprogramowania nie jest rzeczą oczywistą. Jeśli bowiem oprogramowanie przeszło pomyślnie testy użytkownika, nie oznacza to, że będzie działało poprawnie i że nie ma wad fizycznych. Rozpatrywane tu zagadnienia należytej staranności w wykonywaniu zobowiązań dotyczących oprogramowania zostaną celowo zawężone do rozpatrywania jedynie kwestii wad fizycznych produktu, jakim jest oprogramowanie lub system informatyczny. W wyniku wykonania zobowiązania dotyczącego oprogramowania komputerowego lub systemu informatycznego, zamawiający otrzymuje ZAWSZE produkt, który ma wady fizyczne, zarówno ukryte jak i jawne, a wykonawca zobowiązania ma świadomość istnienia tych wad, a na pewno powinien mieć tę świadomość. Jeśli jej nie ma lub zapewnia zamawiającego, że produkt nie ma wad, świadczy to bardzo źle o jego profesjonalizmie. Z reguły wykonawca nie informuje zamawiającego o możliwości istnienia wad, ponieważ jest to dla niego rzecz oczywista i wydaje mu się, że zamawiający również o tym wie, ponieważ wiedzieć powinien jako, że jest to fakt powszechnie znany i nie wymagający dowodu. Pierwszą myślą, jaka w takiej sytuacji nasuwa się prawnikowi jest zażądanie dostarczenia produktu bez wad, usunięcia wad. Jednakże wykonawca nie będzie mógł ich usunąć, ponieważ nie wie ani jakie te wady są, ani gdzie w systemie lub programie się znajdują. Myślenie o oprogramowaniu bez wad przeszło zupełnie do historii na początku lat osiemdziesiątych ubiegłego stulecia. Wraz z rozpowszechnianiem się użycia komputerów i wzrastającym zapotrzebowaniem na nowe, powszechnie używane programy, zaczęto w szybkim tempie wytwarzać oprogramowanie tanie, powszechnie dostępne. Tanie oprogramowanie, szybko wytwarzane i powszechna dostępność te czynniki powodowały, że trzeba było obniżać koszty, nie było czasu na długie testowanie wszystkiego, konkurencja wymuszała

2 szybkie zmiany, Bill Gates wchodził coraz śmielej na rynek ze swoimi produktami. Wszyscy doszli do wniosku, że najwyższa jakość, 100% niezawodność w programach dla komputerów domowych i gier nie jest konieczna. Wtedy to też powstało pojęcie good enough software - oprogramowanie wystarczająco dobre. Później tempo zmian technologicznych i rynkowych, zapotrzebowanie na coraz to nowe programy i coraz bardziej złożone systemy, zmusiło firmy wytwarzające oprogramowanie do pracy w bardzo szybkim tempie, do zatrudniania wielu nowych programistów. Zamiast małych grup kilku programistów współpracujących ze sobą latami, powstały wielkie grupy anonimowych koderów, siedzących przy swoich komputerach i w różnych częściach świata piszących swoje linie kodu, dla kilku projektów jednocześnie. Szybko powstają skomplikowane systemy, ale prawdopodobieństwo wystąpienia błędów rośnie. Skoro taka jest rzeczywistość, to jak można mierzyć jakość oprogramowania lub systemu informatycznego, jak ocenić jakość wykonanego zobowiązania? Czy jest jakaś na to rada i co można zrobić, aby otrzymać w końcu produkt wysokiej jakości? Jakie kroki należy podjąć, jakie środki prawne można zastosować? Nie ma oprogramowania komputerowego ani systemu informatycznego bez defektów. Każde oprogramowanie zawiera defekty pomimo wielokrotnego sprawdzania i testowania. W tym miejscu należałoby ujednolicić pojęcia nakładając na siebie siatkę pojęciową z zakresu inżynierii oprogramowania i prawa. Przyjęte przez prawników i używane na co dzień pojęcie: umowa wdrożeniowa na system IT lub umowa o wdrożenie systemu informatycznego jest bardzo mylące dla inżynierów oprogramowania. W inżynieria oprogramowania pojęcia wdrożenie używa się jedynie na określenie ostatniej tylko fazy projektu informatycznego polegającej na instalacji i uruchomieniu u klienta zbudowanego systemu informatycznego. Szerszym pojęciem jest pojęcie projektu informatycznego. W terminologii inżynierii oprogramowania projekt informatyczny składa się z następujących faz: - pozyskiwania, analizy i specyfikacji wymagań - projektowania architektury systemu - implementacji (programowania) - integracji (scalania) - testowania na wielu poziomach - wdrożenia właściwego, czyli zainstalowania i uruchomienia systemu u klienta Używając pojęć z zakresu inżynierii oprogramowania należałoby stwierdzić, że przedmiotem umowy jest projekt informatyczny, czyli lepiej byłoby może używać nazwy umowa o wykonanie projektu informatycznego lub umowa o projekt informatyczny. Byłaby ona mniej myląca dla jednej ze stron umowy wykonawcy, dla zamawiającego nie ma to praktycznie znaczenia. Rozpatrując problem wad fizycznych produktu jakim jest oprogramowanie lub system informatyczny, konieczne jest precyzyjne ustalenie zakresu znaczenia pojęć używanych w inżynierii oprogramowania i w prawie. Inżynieria oprogramowania posługuje się następującymi pojęciami: 1) błąd działanie ludzkie, pomyłka w trakcie tworzenia oprogramowania

3 2) defekt (potocznie zwany z ang. bug) jest wynikiem błędu ludzkiego, jest to zła część kodu, błędna instrukcja w systemie itp. 3) awaria jest wynikiem defektu, z awarią mamy do czynienia, gdy program nie działa lub działa niepoprawnie. Czy jednak każdy defekt można uznać za wadę w sensie prawnym? Otóż wydaje, się, że nie. Istnieje w kodzie wiele defektów, które nigdy nie zostaną wykryte, dotyczą bowiem tych elementów oprogramowania, które nie mają bezpośredniego wpływu na codzienne użytkowanie systemu, nigdy podczas pracy systemu się nie ujawnią lub mogą ujawnić się dopiero w ekstremalnych warunkach (np. w systemie bankowym defekt doprowadzi do awarii przy temperaturze otoczenia 15 stopni C, a system projektowany jest do pracy w budynku w temperaturze pokojowej ok stopni C). Wydaje się, że jako wady fizyczne systemu lub oprogramowania prawnik zakwalifikuje tylko te defekty, które mogą spowodować awarię. Mają one bezpośredni wpływ na funkcjonalność systemu, stanowią o użytkowych walorach systemu, a co za tym idzie wpływają na gospodarcze interesy zamawiającego. Przedstawione wyżej stwierdzenie dotyczy wszystkich systemów i programów komputerowych, tzn. każdy system i każde oprogramowania będzie miało wady fizyczne. Będą to zarówno wady jawne jak i ukryte. Tu pojawia się kolejny problem terminologiczny - co to są wady jawne, które defekty można uznać za wady ukryte, a które za wady jawne. Wydaje się na pierwszy rzut oka, że wada jawna to taka wada, którą zamawiający jest w stanie wykryć i zauważyć podczas zwykłego użytkowania produktu. Ale co to oznacza w praktyce? Jeśli po włączeniu komputera jakaś aplikacja nie działa to jest to doskonały przykład wady jawnej, ale już przypadek, kiedy to samo zjawisko występuje np. raz w roku, albo przy każdym setnym lub tysięcznym użyciu nie jest taki oczywisty. Wada, którą użytkownik zauważył po trzech dniach użytkowania systemu (czyli dla niego wada jawna) mogła być wcześniej nie zauważona przez wykonawcę i testerów (dla nich będzie to wada ukryta). Czy będziemy ją uważali za wadę jawną czy ukrytą? Wiele jest takich pytań. Odpowiedź na nie wymaga dogłębnej analizy problemu i współpracy interdyscyplinarnej specjalistów z obu dziedzin: prawa i inżynierii oprogramowania. Nie można jednak ignorować rzeczywistości i poruszać się wyłącznie w wyidealizowanym świecie teorii. Biznes wymaga praktycznych rozwiązań na co dzień. W przypadku zobowiązań dotyczących innych dziedzin o wiele łatwiej jest znaleźć mierniki jakości produktów, zabezpieczyć umownie lub ustawowo interesy obu stron kontraktu. Ponieważ każde oprogramowanie i każdy system informatyczny ma wady, więc o jakości produktu, o ocenie sposobu wykonania zobowiązań dotyczących tworzenia i dostarczania oprogramowania lub systemu informatycznego, decydować będzie raczej ocena, czy zachowano lub nie należytą staranność przy jego wytwarzaniu i wdrażaniu. Czyli, czy zrobiono wszystko żeby tych wad było jak najmniej? Na czym jednak będzie polegać zachowanie należytej staranności w przypadku konkretnego oprogramowania lub systemu informatycznego nie jest już sprawą oczywistą. Kiedy można uznać, że wykonanie zobowiązania dotyczącego oprogramowania lub systemu informatycznego odpowiada wymaganiom z art. 355 kc? Czy same wyniki testów mogą być miernikiem jakości oprogramowania? Jak dogłębnie należy testować oprogramowanie i kto o tym powinien decydować? Jak udowodnić, że twórca oprogramowania lub systemu informatycznego dołożył należytej staranności?

4 Kiedy z czystym sumieniem można przestać testować, aby nie ponosić odpowiedzialności za niedoskonałości programu? Dla każdego oprogramowania lub systemu odpowiedź będzie brzmiała różnie, w zależności od jego złożoności oraz przeznaczenia. Istnieją jednak pewne podstawowe elementy wspólne dla oceny sposobu wykonywania zobowiązania. Po pierwsze: Żądając od wykonawcy poprawnego wykonania zobowiązania, trzeba jasno i bardzo precyzyjnie określić wymagania. Na tym początkowym etapie tworzenia oprogramowania komputerowego lub systemu informatycznego, współpraca zamawiającego i wykonawcy jest konieczna i bardzo istotna. Obie strony muszą dołożyć należytej staranności we współdziałaniu. Jeśli zamawiającemu zależy na wysokiej jakości produktu, musi określić swoje wymagania bardzo szczegółowo, precyzyjnie i jednoznacznie, przyjmując, że nie ma rzeczy oczywistych. To, co dla jednego specjalisty jest oczywistością, dla programisty może być zupełnie niezrozumiałe. Dział inżynierii oprogramowania zajmujący się zagadnieniami wymagań, nazywa się inżynierią wymagań, a dokument opisujący wymagania, stanowiący podstawę pracy dla architektów oprogramowania komputerowego lub systemu informatycznego i programistów, nazywa się zwykle specyfikacją wymagań. Cennym elementem ułatwiającym rozstrzyganie sporów dotyczących jakości produktu końcowego, może być włączenie specyfikacji wymagań do umowy. Po drugie: Na etapie tworzenia oprogramowania komputerowego lub systemu informatycznego, zamawiający ma najmniejsze możliwości sprawdzenia i oceny sposobu wykonywania zobowiązania, jednakże istnieją pewne normy, zespoły dobrych praktyk, przyjęte i opisane metody oraz procedury postępowania, dotyczące procesów inżynierii oprogramowania. Przestrzeganie tych zasad lub norm, powołanie się na nie w umowie lub ew. w protokołach odbioru stanowi element zapewnienia wysokiej jakości produktu i może być uznane za przejaw wykazywania należytej staranności. Po trzecie: Weryfikowanie jakości produktu w trakcie jego tworzenia i produktu końcowego, czyli testowanie. Co, kiedy i jak testować? Dla każdego oprogramowania lub systemu odpowiedź będzie brzmiała różnie, w zależności od jego złożoności oraz przeznaczenia. Nie jest konieczne wykonywanie bardzo dogłębnego testowania na przykład pełnej analizy statycznej kodu źródłowego - w przypadku małego systemu do zarządzania rozgrywkami szkolnej ligi siatkówki. Tu wystąpienie ewentualnej awarii systemu jest być może kłopotliwe, ale nie bardzo groźne, a szkolnej ligii siatkówki nie stać na bardzo drogi system, chyba, ze wykonają go za darmo studenci informatyki w ramach ćwiczeń programowych. Niestety, wyższe uczelnie na wydziałach informatyki zaniedbują w programach nauczanie inżynierii jakości, a szczególnie zagadnienia testowania traktują marginalnie. A przecież w przypadku nawet małego programu mającego zastosowanie np. w medycynie testowania nigdy dość, tu najmniejszy nawet błąd może spowodować śmierć wielu osób.

5 W przypadku testowania oprogramowania lub systemu należy zawsze znaleźć złoty środek pomiędzy ryzykiem wystąpienia awarii, kosztami i czasem poświęconym testowaniu, tak, aby w końcowym efekcie otrzymać produkt właściwej jakości: niezawodny na miarę potrzeb. Sporządzając umowę, dobrze jest zawrzeć w niej ustalenia co do sposobu testowania oprogramowania komputerowego lub systemu informatycznego, na jakich etapach budowania projektu będą one wykonywane oraz ew. zażądać dołączenia raportów testowych do dokumentacji odbioru produktu. Zamawiający musi mieć świadomość, ze każde dokonanie zmian na poszczególnych etapach tworzenia oprogramowania komputerowego lub systemu informatycznego zwiększa ryzyko zaistnienia defektów, wymusza dodatkowe testy i wydłuża czas wykonania zobowiązania. Dlatego też chcąc zapewnić sobie wysoką jakość produktu końcowego, należy na etapach wstępnych poświęcić więcej uwagi i pracy przygotowaniom. Koszty wydane na przygotowania zwracają się wielokrotnie w postaci niezawodności i jakości oprogramowania lub systemu. Nie można też żądać rzeczy niemożliwych: np. zbudowania i wdrożenia systemu w miesiąc, bez podania specyfikacji wymagań, dokonując zmian co trzy dni, zostawiając dwa dni na testowanie! Przedstawione powyżej sugestie działań ze strony zamawiającego jasno wskazują, że powinien on zarówno na etapie sporządzania umowy jak i odbioru oraz oceny oprogramowania komputerowego lub systemu informatycznego korzystać z pomocy profesjonalisty. Wydaje się, że nie da się tego uniknąć. Wiedza powszechnie dostępna nieprofesjonalistom zupełnie nie wystarcza do oceny prawidłowości całego procesu, konsekwencje zaniedbań mogą być dla zamawiającego bardzo poważne. Bez wątpienia podnosi to koszty całego projektu informatycznego, ale w konsekwencji podnosi jakość produktu, a jakość zawsze się opłaca. Podsumowując trzeba stwierdzić, że trudno jest jednoznacznie określić, czym jest należyta staranność w wykonaniu zobowiązania, którego przedmiotem jest oprogramowanie komputerowe lub projekt informatyczny. Dla każdego projektu, należałoby przyjąć inne kryteria, mając na względzie jego gospodarcze przeznaczenie. Zawsze jednak należy domagać się zachowania obowiązujących standardów i dobrych praktyk oraz zachować zdrowy rozsądek, dla którego jeszcze nie wynaleziono miary. Magdalena Kowalska Absolwentka Wydziału Prawa i Administracji Uniwersytetu Warszawskiego oraz Szkoły Głównej Handlowej - studium podyplomowego Zarządzanie biznesem międzynarodowym W przeszłości pracownik naukowy Instytutu Nauk Prawnych Polskiej Akademii Nauk i nauczyciel akademicki w Szkole Głównej Gospodarstwa Wiejskiego W swojej karierze zawodowej była także urzędnikiem centralnej administracji państwowej, między innymi wice-dyrektorem gabinetu ministra

6 Ma doświadczenie w dziedzinie zarządzania projektami, kierowała między innymi częścią projektu prywatyzacyjnego NFI. Specjalistka we wdrażaniu programów pomocowych UE Od 12 lat doradca inwestorów zagranicznych w Polsce w sektorze poligraficznym, paliwowym, zarządzaniu strefami wolnocłowymi Specjalista w dziedzinie zarządzania, zajmowała się postępowaniami naprawczymi i restrukturyzacją podmiotów gospodarczych sektorze MSP, przedsiębiorca Prawdopodobnie, jako jedyny prawnik w Polsce - zdała egzamin i zdobyła międzynarodowy certyfikat w zakresie testowania oprogramowania komputerowego wydawany przez International Software Testing Qualification Board Zna język francuski, włoski, angielski i rosyjski Od 1992 roku jest prezesem zarządu Fundacji Św. Marka na Rzecz Osób Niepełnosprawnych i Potrzebujących Pomocy

Umowy IT zabezpieczenie interesów stron

Umowy IT zabezpieczenie interesów stron Umowy IT zabezpieczenie interesów stron Centrum Projektów Informatycznych Warszawa, dnia 28 lutego 2012 r. Podstawa prawna zawierania umów (KC) Umowa to stan faktyczny polegający na złożeniu dwóch lub

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

Szkolenia zgodne z sylabusem ISTQB. www.cts.com.pl

Szkolenia zgodne z sylabusem ISTQB. www.cts.com.pl Szkolenia zgodne z sylabusem www.cts.com.pl DLACZEGO WARTO PRZYJŚĆ NA DO CERTYFIKATU? Aby dostarczyć klientom potrzebną jakość, konieczne jest testowanie produktów informatycznych. O największych awariach,

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRZEWODNIK PO PRZEDMIOCIE C1. Podniesienie poziomu wiedzy studentów z inżynierii oprogramowania w zakresie C.

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

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

2016 CONSULTING DLA MŚP. Badanie zapotrzebowania na usługi doradcze

2016 CONSULTING DLA MŚP. Badanie zapotrzebowania na usługi doradcze 2016 CONSULTING DLA MŚP Badanie zapotrzebowania na usługi doradcze 1 O raporcie Wraz ze wzrostem świadomości polskich przedsiębiorców rośnie zapotrzebowanie na różnego rodzaju usługi doradcze. Jednakże

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

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

ZAPISY SIWZ ZABEZPIECZAJĄCE ZAMAWIAJĄCEGO TYLKO PRZED CZYM?

ZAPISY SIWZ ZABEZPIECZAJĄCE ZAMAWIAJĄCEGO TYLKO PRZED CZYM? ZAPISY SIWZ ZABEZPIECZAJĄCE ZAMAWIAJĄCEGO TYLKO PRZED CZYM? Andrzej Dopierała Od 1998 roku prezes polskich oddziałów korporacji IT Ta historia zaczyna się od tego, gdy przedsiębiorstwo/instytucja ( Zamawiający

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

INFORMATYKA PLAN STUDIÓW NIESTACJONARNYCH. Podstawy programowania 15 30 45 1 7. Systemy operacyjne 20 25 45 5

INFORMATYKA PLAN STUDIÓW NIESTACJONARNYCH. Podstawy programowania 15 30 45 1 7. Systemy operacyjne 20 25 45 5 razem razem INFORMATYKA PLAN STUDIÓ NISTACJONARNYCH ( U K Ł A D Z I R O C Z N Y M ) Rok I Zajęcia dydaktyczne obligatoryjne Podstawy programowania 15 30 45 1 7 Systemy operacyjne 20 25 45 5 Teoretyczne

Bardziej szczegółowo

JAK PRAWIDŁOWO ZAMAWIAĆ SYSTEM INFORMATYCZNY DLA SZPITALA PERSPEKTYWA OBSERWATORA

JAK PRAWIDŁOWO ZAMAWIAĆ SYSTEM INFORMATYCZNY DLA SZPITALA PERSPEKTYWA OBSERWATORA Fundacja Wolnego i Otwartego Oprogramowania (FWiOO) JAK PRAWIDŁOWO ZAMAWIAĆ SYSTEM INFORMATYCZNY DLA SZPITALA PERSPEKTYWA OBSERWATORA AGATA MICHAŁEK-BUDZICZ ul. Staszica 25/8, 60-524 Poznań, tel.: +48.

Bardziej szczegółowo

KARTA PRZEDMIOTU. 1. NAZWA PRZEDMIOTU: Zespołowy projekt informatyczny. 2. KIERUNEK: Matematyka. 3. POZIOM STUDIÓW: I stopnia

KARTA PRZEDMIOTU. 1. NAZWA PRZEDMIOTU: Zespołowy projekt informatyczny. 2. KIERUNEK: Matematyka. 3. POZIOM STUDIÓW: I stopnia KARTA PRZEDMIOTU 1. NAZWA PRZEDMIOTU: Zespołowy projekt informatyczny 2. KIERUNEK: Matematyka 3. POZIOM STUDIÓW: I stopnia 4. ROK/ SEMESTR STUDIÓW: III/6 5. LICZBA PUNKTÓW ECTS: 4 6. LICZBA GODZIN: 30

Bardziej szczegółowo

Współpraca pracowników naukowych z parkami technologicznymi na przykładzie Finlandii - propozycja implementacji rozwiązań dla Polski

Współpraca pracowników naukowych z parkami technologicznymi na przykładzie Finlandii - propozycja implementacji rozwiązań dla Polski Współpraca pracowników naukowych z parkami technologicznymi na przykładzie Finlandii - propozycja implementacji rozwiązań dla Polski Dr inż. MBA Janusz Marszalec Centrum Edisona, Warszawa 8 kwietnia 2014

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

1. Wyjaśnienia/Zmiana treści specyfikacji istotnych warunków zamówienia/przedłużenie terminu składania ofert

1. Wyjaśnienia/Zmiana treści specyfikacji istotnych warunków zamówienia/przedłużenie terminu składania ofert Sygnatura postępowania: BZP/31/DRI/2015 BGK BANK GOSPODARSTWA KRAJOWEGO Warszawa, 8 lipiec 2015 r. Zamawiający: Bank Gospodarstwa Krajowego Al. Jerozolimskie 7 00-955 Warszawa Biuro Zamówień Publicznych

Bardziej szczegółowo

Metodyka projektowania komputerowych systemów sterowania

Metodyka projektowania komputerowych systemów sterowania Metodyka projektowania komputerowych systemów sterowania Andrzej URBANIAK Metodyka projektowania KSS (1) 1 Projektowanie KSS Analiza wymagań Opracowanie sprzętu Projektowanie systemu Opracowanie oprogramowania

Bardziej szczegółowo

Aplikacje internetowe i mobilne w zarządzaniu

Aplikacje internetowe i mobilne w zarządzaniu Aplikacje internetowe i mobilne w zarządzaniu WSB Bydgoszcz - Studia podyplomowe Opis kierunku Aplikacje Mobilne w Zarządzaniu- Studia w WSB w Bydgoszczy Rozwój Internetu, a zarazem technologii wspierających

Bardziej szczegółowo

UMOWA O WYKONANIE PROGRAMU KOMPUTEROWEGO. 2. Firmą z siedzibą w. przy ul., kod pocztowy..-..., REGON, NIP

UMOWA O WYKONANIE PROGRAMU KOMPUTEROWEGO. 2. Firmą z siedzibą w. przy ul., kod pocztowy..-..., REGON, NIP UMOWA O WYKONANIE PROGRAMU KOMPUTEROWEGO Zawarta w dnia. roku pomiędzy: 1. Firmą z siedzibą w. przy ul..., kod pocztowy.-..., REGON., NIP..,wpisaną do rejestru przedsiębiorców prowadzonego przez Sąd Rejonowy

Bardziej szczegółowo

Katalog szkoleń certyfikowanych Testowanie Oprogramowania

Katalog szkoleń certyfikowanych Testowanie Oprogramowania Katalog szkoleń certyfikowanych Testowanie Oprogramowania Szanowni Państwo, Certyfikowane szkolenia testerzy.pl to dwie uznane ścieżki szkoleniowe dla testerów ISTQB oraz ISEB. Dostarczamy pełny zakres

Bardziej szczegółowo

Grażyna Gończar Konsultant ds. Funduszy UE. STRATEGOR Wielkopolskie Centrum Ekspertyz Finansowych

Grażyna Gończar Konsultant ds. Funduszy UE. STRATEGOR Wielkopolskie Centrum Ekspertyz Finansowych Grażyna Gończar Konsultant ds. Funduszy UE STRATEGOR Wielkopolskie Centrum Ekspertyz Finansowych Kilka słów o nas Nasze sukcesy i nasze doświadczenie Kredyt technologiczny w oczach przedsiębiorców 4.3

Bardziej szczegółowo

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO WSPARCIA UŻYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO WSPARCIA UŻYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ Załącznik nr 6 do SIWZ WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO WSPARCIA UŻYTKOWNIKÓW HELP DESK ORAZ ASYSTY TECHNICZNEJ I. Warunki ogólne 1. Wykonawca zobowiązany jest do udzielenia Zamawiającemu gwarancji

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

Techniki (automatyzacji) projektowania testów. Adam Roman WarszawQA, 24 II 2016

Techniki (automatyzacji) projektowania testów. Adam Roman WarszawQA, 24 II 2016 Techniki (automatyzacji) projektowania testów Adam Roman WarszawQA, 24 II 2016 Prelegent Quality Assurance R&D Lead, Rivet Group Adiunkt w Instytucie Informatyki i Matematyki Komputerowej UJ Członek Stowarzyszenia

Bardziej szczegółowo

Katalog szkoleń certyfikowanych Testowanie oprogramowania

Katalog szkoleń certyfikowanych Testowanie oprogramowania Katalog szkoleń certyfikowanych Testowanie oprogramowania Szanowni Państwo, Certyfikowane szkolenia testerzy.pl to dwie uznane ścieżki szkoleniowe dla testerów ISTQB oraz ISEB. Dostarczamy pełny zakres

Bardziej szczegółowo

Specjalizacja: Zarządzanie projektami (I)

Specjalizacja: Zarządzanie projektami (I) Specjalizacja: Zarządzanie projektami (I) Osoba koordynująca: dr inż. Tomasz Pieciukiewicz Tomasz.Pieciukiewicz1@pjwstk.edu.pl Czego uczymy. Umiejętności po ukończeniu specjalizacji. Celem specjalizacji

Bardziej szczegółowo

Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 32-CPI-WZP-2244/13. Podstawa do dysponowania osobą

Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 32-CPI-WZP-2244/13. Podstawa do dysponowania osobą Załącznik nr 8 do SIWZ Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 3-CPI-WZP-44/13 Lp. Zakres wykonywanych czynności Liczba osób Imiona i nazwiska osób, którymi dysponuje wykonawca

Bardziej szczegółowo

Załącznik Nr 6 do siwz. UMOWA (projekt)

Załącznik Nr 6 do siwz. UMOWA (projekt) Załącznik Nr 6 do siwz UMOWA (projekt) zawarta w dniu... r. pomiędzy Samodzielnym Publicznym Zakładem Opieki Zdrowotnej z siedzibą w Parczewie 21-200, ul. Kościelna 136, zarejestrowanym w Sądzie Rejonowym

Bardziej szczegółowo

KARTA MODUŁU KSZTAŁCENIA

KARTA MODUŁU KSZTAŁCENIA KARTA MODUŁU KSZTAŁCENIA I. Informacje ogólne 1 Nazwa modułu kształcenia Inżynieria 2 Nazwa jednostki prowadzącej moduł Instytut Informatyki, Zakład Informatyki Stosowanej 3 Kod modułu (wypełnia koordynator

Bardziej szczegółowo

ZARZĄDZANIE PROCESEM TESTOWYM (SQAM Test Manager) 7-8 luty 2008, Warszawa Zdobądź z nami certyfikat SQAM Test Manager.

ZARZĄDZANIE PROCESEM TESTOWYM (SQAM Test Manager) 7-8 luty 2008, Warszawa Zdobądź z nami certyfikat SQAM Test Manager. ZARZĄDZANIE PROCESEM TESTOWYM (SQAM Test Manager) 7-8 luty 2008, Warszawa Zdobądź z nami certyfikat SQAM Test Manager. Na szkolenie zapraszamy: testerów kierowników działów testowych analityków systemowych

Bardziej szczegółowo

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Krzysztof Wertejuk audytor wiodący ISOQAR CEE Sp. z o.o. Dlaczego rozwiązania

Bardziej szczegółowo

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO ORAZ ASYSTY TECHNICZNEJ

WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO ORAZ ASYSTY TECHNICZNEJ Załącznik nr 6 do SIWZ WARUNKI ŚWIADCZENIA SERWISU GWARANCYJNEGO ORAZ ASYSTY TECHNICZNEJ I. Warunki ogólne 1. Wykonawca zobowiązany jest do udzielenia Zamawiającemu gwarancji na przedmiot Umowy i zobowiązuje

Bardziej szczegółowo

Ośrodek Kształcenia na Odległość OKNO Politechniki Warszawskiej 2015r.

Ośrodek Kształcenia na Odległość OKNO Politechniki Warszawskiej 2015r. Opis przedmiotu Kod przedmiotu PGOZ Nazwa przedmiotu Prawo gospodarcze Wersja przedmiotu 1 A. Usytuowanie przedmiotu w systemie studiów Poziom kształcenia Studia I stopnia Forma i tryb prowadzenia studiów

Bardziej szczegółowo

Opis Przedmiotu Zamówienia

Opis Przedmiotu Zamówienia Załącznik nr 1 do SIWZ/ załącznik nr 1 do umowy OP/UP/099/2011 Opis Przedmiotu Zamówienia 1. Przedmiot zamówienia 1.1. Przedmiotem zamówienia jest świadczenie usług konsultancko-developerskich dla systemu

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

Pytania w ramach opublikowania postępowania znak postępowania: WORD/D/23/144/W/2015.

Pytania w ramach opublikowania postępowania znak postępowania: WORD/D/23/144/W/2015. Pytania w ramach opublikowania postępowania znak postępowania: WORD/D/23/144/W/2015. 1. Załącznik 2 - Warunki Gwarancji i Utrzymania czy linia Awaria powinna być również dostępna w dniu ustawowo wolnym

Bardziej szczegółowo

LearnIT project PL/08/LLP-LdV/TOI/140001

LearnIT project PL/08/LLP-LdV/TOI/140001 LearnIT project PL/08/LLP-LdV/TOI/140001 Biuletyn Wydanie 7 Lipiec 2010 Drogi czytelniku, Prezentujemy z przyjemnością siódme wydanie biuletynu LearnIT. W tym wydaniu chcielibyśmy poinformować Cię o przebiegu

Bardziej szczegółowo

Certyfikowane szkolenia testerzy.pl to uznana ścieżka szkoleniowa ISTQB dla testerów.

Certyfikowane szkolenia testerzy.pl to uznana ścieżka szkoleniowa ISTQB dla testerów. Szanowni Państwo Certyfikowane szkolenia testerzy.pl to uznana ścieżka szkoleniowa ISTQB dla testerów. Dostarczamy pełny zakres usług w procesie odpowiedniego przygotowania uczestników do egzaminów. Dostarczamy

Bardziej szczegółowo

214/IH/PN/7/2014. zwanym dalej: Wykonawcą. lub

214/IH/PN/7/2014. zwanym dalej: Wykonawcą. lub UMOWA /214/2014 na zamówienie publiczne udzielone na podstawie art. 39 ustawy Prawo zamówień publicznych z dnia 29 stycznia 2004 r. (Dz. U. z 2010 r. Nr 113, poz. 759 z póżn. zm.) zawarta w dniu..w Warszawie

Bardziej szczegółowo

W badaniach 2008 trzecioklasiści mieli kilkakrotnie za zadanie wyjaśnić wymyśloną przez siebie strategię postępowania.

W badaniach 2008 trzecioklasiści mieli kilkakrotnie za zadanie wyjaśnić wymyśloną przez siebie strategię postępowania. Alina Kalinowska Jak to powiedzieć? Każdy z nas doświadczał z pewnością sytuacji, w której wiedział, ale nie wiedział, jak to powiedzieć. Uczniowie na lekcjach matematyki często w ten sposób przekonują

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

Sekcja I: Instytucja zamawiająca/podmiot zamawiający

Sekcja I: Instytucja zamawiająca/podmiot zamawiający Unia Europejska Publikacja Suplementu do Dziennika Urzędowego Unii Europejskiej 2, rue Mercier, 2985 Luxembourg, Luksemburg Faks: +352 29 29 42 670 E-mail: ojs@publications.europa.eu Informacje i formularze

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

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

Uczysz się przez 4 lata w szkole i co dalej???

Uczysz się przez 4 lata w szkole i co dalej??? Uczysz się przez 4 lata w szkole i co dalej??? Każdy z Was chce, aby czas poświęcony na naukę w efekcie przyniósł jak największe korzyści... Jakie korzyści??? wiedzę, bo liczy się ekspert pieniądze, bo

Bardziej szczegółowo

Testowanie oprogramowania

Testowanie oprogramowania Testowanie oprogramowania Adam Roman Instytut Informatyki UJ Sprawy organizacyjne organizacja zajęć program kursu informacja o egzaminie 1/17 Informacje kontaktowe Adam Roman Instytut Informatyki UJ pokój

Bardziej szczegółowo

Zwrot z inwestycji w IT: prawda czy mity

Zwrot z inwestycji w IT: prawda czy mity Zwrot z inwestycji w IT: prawda czy mity Inwestycje w technologie IT 1 muszą podlegać takim samym regułom oceny, jak wszystkie inne: muszą mieć ekonomiczne uzasadnienie. Stanowią one koszty i jako takie

Bardziej szczegółowo

Źródła dumy zawodowej testera oprogramowania

Źródła dumy zawodowej testera oprogramowania Źródła dumy zawodowej testera oprogramowania Tom Gilb & Kai Gilb: False QA is calling your activity QA when in fact you only do testing. http://www.result-planning.com/real+qa+manifesto Nie jestem QA!

Bardziej szczegółowo

Scala Business Solutions Polska Sp. z o.o. Signature metodologia wdrażania Scali. Czego użytkownik potrzebuje najbardziej?

Scala Business Solutions Polska Sp. z o.o. Signature metodologia wdrażania Scali. Czego użytkownik potrzebuje najbardziej? Signature metodologia wdrażania Scali Scala to zintegrowany pakiet do zarządzania przedsiębiorstwem. O efektywności jego działania decyduje sposób właściwego wdrożenia, toteż gorąco zachęcamy wszystkich

Bardziej szczegółowo

Ustawa o zwalczaniu nieuczciwej konkurencji a ustawa Prawo własności przemysłowej. Różnice procesowe. Szkic problematyki

Ustawa o zwalczaniu nieuczciwej konkurencji a ustawa Prawo własności przemysłowej. Różnice procesowe. Szkic problematyki Ustawa o zwalczaniu nieuczciwej konkurencji a ustawa Prawo własności przemysłowej Różnice procesowe. Szkic problematyki Zasady ochrony Ustawa Prawo własności przemysłowej chroni prawa podmiotowe, niezależnie

Bardziej szczegółowo

ZARZĄDZANIE I INŻYNIERIA PRODUKCJI

ZARZĄDZANIE I INŻYNIERIA PRODUKCJI ZARZĄDZANIE I INŻYNIERIA PRODUKCJI STUDIA PIERWSZEGO STOPNIA PROFIL OGÓLNOAKADEMICKI Załącznik nr 2 Odniesienie efektów kierunkowych do efektów obszarowych i odwrotnie Załącznik nr 2a - Tabela odniesienia

Bardziej szczegółowo

Dobór systemów klasy ERP

Dobór systemów klasy ERP klasy ERP - z uwzględnieniem wymagań normy ISO 9001 Prezentacja w Klubie Menedżera Jakości, 19 marzec 2008 Zagadnienia ogólne związane z doborem systemu klasy ERP Podstawowe podziały klasyfikujące systemy

Bardziej szczegółowo

Wyższa Szkoła Technologii Teleinformatycznych w Świdnicy. Dokumentacja specjalności. Systemy komputerowe administracji

Wyższa Szkoła Technologii Teleinformatycznych w Świdnicy. Dokumentacja specjalności. Systemy komputerowe administracji Wyższa Szkoła Technologii Teleinformatycznych w Świdnicy Dokumentacja specjalności Systemy komputerowe administracji prowadzonej w ramach kierunku Informatykana wydziale Informatyki 1. Dane ogólne Nazwa

Bardziej szczegółowo

Działanie 1.1. Tworzenie warunków dla rozwoju innowacyjności

Działanie 1.1. Tworzenie warunków dla rozwoju innowacyjności Działanie 1.1. Tworzenie warunków dla rozwoju innowacyjności Kryteria merytoryczno-techniczne dopuszczające szczególne L.p. Kryterium tak nie nie dotyczy 1 Trwałość prowadzonej działalności z zakresu innowacji

Bardziej szczegółowo

Popularyzacja podpisu elektronicznego w Polsce

Popularyzacja podpisu elektronicznego w Polsce Popularyzacja podpisu elektronicznego w Polsce Rola administracji w budowaniu gospodarki elektronicznej Warszawa, 25 września 2006 r. Poruszane tematy Wprowadzenie i kontekst prezentacji Rola administracji

Bardziej szczegółowo

ISTQB Foundation Level

ISTQB Foundation Level ISTQB Foundation Level Szkolenie przeznaczone jest dla osób chcących uzyskać certyfikat ISTQB Certified Tester Foundation Level/ISTQB Certyfikowany Tester Poziom Podstawowy Przygotowanie do egzaminu ISTQB

Bardziej szczegółowo

KIERUNKOWE EFEKTY KSZTAŁCENIA

KIERUNKOWE EFEKTY KSZTAŁCENIA WYDZIAŁ INFORMATYKI I ZARZĄDZANIA Kierunek studiów: INFORMATYKA Stopień studiów: STUDIA II STOPNIA Obszar Wiedzy/Kształcenia: OBSZAR NAUK TECHNICZNYCH Obszar nauki: DZIEDZINA NAUK TECHNICZNYCH Dyscyplina

Bardziej szczegółowo

20-02-2008. Wprowadzenie. Wybór rozwiązania. Wdrożenie (studium przypadków) proalpha golive! - metoda i narzędzie

20-02-2008. Wprowadzenie. Wybór rozwiązania. Wdrożenie (studium przypadków) proalpha golive! - metoda i narzędzie 5. Wybór i wdrożenie u ERP Wprowadzenie Wybór rozwiązania Wdrożenie (studium przypadków) golive! - metoda i narzędzie Wymagania rynku; potrzeba wdrożenia nowych rozwiązań coraz krótsze terminy realizacji

Bardziej szczegółowo

Jacek Bajorek Instytut Zarządzana Bezpieczeństwem Informacji

Jacek Bajorek Instytut Zarządzana Bezpieczeństwem Informacji Jacek Bajorek Instytut Zarządzana Bezpieczeństwem Informacji Outsourcing, czyli skrót angielskich wyrazów outsideresource-ing oznacza nie mniej, nie więcej, jak wykorzystywanie zasobów z zewnątrz. Coraz

Bardziej szczegółowo

Inżynieria oprogramowania (Software Engineering)

Inżynieria oprogramowania (Software Engineering) Inżynieria oprogramowania (Software Engineering) Wykład 3 Studium wykonalności Definicja wymagań Studium wykonalności (feasibility study) Prowadzone przed rozpoczęciem projektu, krótkie, niekosztowne badanie

Bardziej szczegółowo

Szczegółowy opis przedmiotu zamówienia

Szczegółowy opis przedmiotu zamówienia Załącznik nr 2 do Zapytania Ofertowego nr 07/04/IT/2016 Szczegółowy opis przedmiotu zamówienia Utrzymanie i rozwój systemów GREX, SPIN, TK, AMOC, Obsługa Rewidentów 1 SPIS TREŚCI Wprowadzenie... 3 1. Specyfikacja

Bardziej szczegółowo

Wyższa Szkoła Technologii Teleinformatycznych w Świdnicy. Dokumentacja specjalności. Informatyka w działalności biznesowej

Wyższa Szkoła Technologii Teleinformatycznych w Świdnicy. Dokumentacja specjalności. Informatyka w działalności biznesowej Wyższa Szkoła Technologii Teleinformatycznych w Świdnicy Dokumentacja specjalności Informatyka w działalności biznesowej prowadzonej w ramach kierunku Informatyka na wydziale Informatyki 1. Dane ogólne

Bardziej szczegółowo

Sylabus: Zdrowie Publiczne

Sylabus: Zdrowie Publiczne Sylabus: Zdrowie Publiczne Wydział / Kierunek / Specjalność WYDZIAŁ NAUK o ZDROWIU/ZDROWIE PUBLICZNE Zarządzanie w opiece zdrowotnej INFORMACJE OGÓLNE Studia (odpowiednie podkreślić) I stopnia - stacjonarne

Bardziej szczegółowo

Informatyka w kontroli i audycie

Informatyka w kontroli i audycie Informatyka w kontroli i audycie Informatyka w kontroli i audycie Wstęp Terminy zajęć 30.11.2013 - godzina 8:00-9:30 ; 9:45-11:15 15.12.2013 - godzina 8:00-9:30 ; 9:45-11:15 05.04.2014 - godzina 15:45-17:15

Bardziej szczegółowo

Istotne postanowienia umowy

Istotne postanowienia umowy Załącznik nr 7 Istotne postanowienia umowy Zgodnie z wynikiem postępowania o udzielenie zamówienia publicznego w trybie przetargu nieograniczonego o wartości nieprzekraczającej kwoty określonej w przepisach

Bardziej szczegółowo

WARUNKI GWARANCJI I SERWISU GWARANCYJNEGO

WARUNKI GWARANCJI I SERWISU GWARANCYJNEGO Załącznik nr 3 do Umowy nr.. z dnia r. Warunki gwarancji i serwisu gwarancyjnego WARUNKI GWARANCJI I SERWISU GWARANCYJNEGO 1. Definicję pojęć: Celem opisania warunków świadczenia usług serwisowych definiuje

Bardziej szczegółowo

Załącznik nr 2 do SIWZ

Załącznik nr 2 do SIWZ Załącznik nr 2 do SIWZ Opis Przedmiotu Zamówienia (zwany dalej OPZ), zawierający wymagania Zamawiającego do Umowy na świadczenie usług serwisowych systemu zapewniającego, przy wykorzystaniu interfejsu

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

OFERTA 1. Dla koncernu naftowego poszukujemy osoby na stanowisko: Menadżer ds. Geologii/Rolnictwa/Geodezji Miejsce pracy: cała Polska.

OFERTA 1. Dla koncernu naftowego poszukujemy osoby na stanowisko: Menadżer ds. Geologii/Rolnictwa/Geodezji Miejsce pracy: cała Polska. OFERTA 1 Dla koncernu naftowego poszukujemy osoby na stanowisko: Menadżer ds. Geologii/Rolnictwa/Geodezji Miejsce pracy: cała Polska Obowiązki: nadzorowanie pracy geologów i geofizyków, realizowanie programu

Bardziej szczegółowo

Powierzchnie biurowe Inkubator dla nowych firm i startupów IT Mix najemców stymulującej kooperacji Baza konferencyjno-szkoleniowa

Powierzchnie biurowe Inkubator dla nowych firm i startupów IT Mix najemców stymulującej kooperacji Baza konferencyjno-szkoleniowa Wsparcie innowacyjnej przedsiębiorczości, rozwoju nowoczesnych technologii oraz gospodarki opartej na wiedzy Ułatwienia dla rozwoju małych i średnich przedsiębiorstw Dynamiczny wzrost sektora usług biznesowych

Bardziej szczegółowo

Grzegorz Ruciński. Warszawska Wyższa Szkoła Informatyki 2011. Promotor dr inż. Paweł Figat

Grzegorz Ruciński. Warszawska Wyższa Szkoła Informatyki 2011. Promotor dr inż. Paweł Figat Grzegorz Ruciński Warszawska Wyższa Szkoła Informatyki 2011 Promotor dr inż. Paweł Figat Cel i hipoteza pracy Wprowadzenie do tematu Przedstawienie porównywanych rozwiązań Przedstawienie zalet i wad porównywanych

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

Z roku na rok wzrasta liczba systemów informatycznych, co skutkuje coraz większym uzależnieniem od nich działalności biznesowej przedsiębiorstw.

Z roku na rok wzrasta liczba systemów informatycznych, co skutkuje coraz większym uzależnieniem od nich działalności biznesowej przedsiębiorstw. Single Sign On Z roku na rok wzrasta liczba systemów informatycznych, co skutkuje coraz większym uzależnieniem od nich działalności biznesowej przedsiębiorstw. Jednocześnie systemy te przechowują coraz

Bardziej szczegółowo

WYŻSZA SZKOŁA BEZPIECZEŃSTWA z siedzibą w Poznaniu PROGRAM KSZTAŁCENIA PROJEKTY UNIJNE I POZYSKIWANIE FUNDUSZY Z UE

WYŻSZA SZKOŁA BEZPIECZEŃSTWA z siedzibą w Poznaniu PROGRAM KSZTAŁCENIA PROJEKTY UNIJNE I POZYSKIWANIE FUNDUSZY Z UE PROGRAM KSZTAŁCENIA Kierunek Obszar/obszary kształcenia, w których umiejscowiony jest kierunek studiów Dziedziny nauki, w których umiejscowiony jest kierunek studiów/ Dyscypliny naukowe, w których umiejscowiony

Bardziej szczegółowo

Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Fundation

Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Fundation Akredytowane szkolenie i egzamin. Zarządzanie projektami w oparciu o metodykę PRINCE2 Fundation Opis Progress Project zaprasza do zapoznania się z programem szkolenia organizowanego przez partnera szkoleniowego,

Bardziej szczegółowo

Sukces vs porażka. Sukces. Porażka

Sukces vs porażka. Sukces. Porażka Wstęp Cytaty Kiedy zawiesza się program konkurencji, to jest awaria. Kiedy zawiesza się własny program, to jest drobiazg. Często po awarii pojawia się komunikat typu ID 02. ID to skrót od idiotyczny drobiazg,

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

Fiszka oferty usług proinnowacyjnych

Fiszka oferty usług proinnowacyjnych Fiszka oferty usług proinnowacyjnych I. Akredytowany wykonawca 1. Nazwa wykonawcy "MERITUM" LUBELSKA GRUPA DORADCZA SPÓŁKA Z OGRANICZONĄ ODPOWIEDZIALNOŚCIĄ 2. Forma prawna prowadzonej działalności Spółka

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

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

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

Koszty związane z tworzeniem aplikacji on demand versus zakup gotowych rozwiązań

Koszty związane z tworzeniem aplikacji on demand versus zakup gotowych rozwiązań 2012 Koszty związane z tworzeniem aplikacji on demand versus zakup gotowych rozwiązań Mateusz Kurleto NEOTERIC Wdrożenie systemu B2B Lublin, 25 października 2012 Mateusz Kurleto Od 2005 r. właściciel NEOTERIC,

Bardziej szczegółowo

KATALOG SZKOLEŃ CERTYFIKOWANYCH 2014

KATALOG SZKOLEŃ CERTYFIKOWANYCH 2014 KATALOG SZKOLEŃ CERTYFIKOWANYCH 2014 Szanowni Państwo! Misją testerzy.pl jest propagowanie testowania oprogramowania i zapewnienia jakości. Dostarczamy najwyższej jakości usługi i szkolenia dedykowane

Bardziej szczegółowo

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014

Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014 1 QUO VADIS.. BS? Rekomendacja D dlaczego? Mocne fundamenty to dynamiczny rozwój. Rzeczywistość wdrożeniowa. 2 Determinanty sukcesu w biznesie. strategia, zasoby (ludzie, kompetencje, procedury, technologia)

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: Kierunek: Mechatronika Rodzaj przedmiotu: inne Rodzaj zajęć: obserwacyjne/praktyczne I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRAKTYKA ZAWODOWA TRAINEESHIP Forma studiów: stacjonarne Poziom

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

Specyfikacja usług. 1. Zakup usług informatycznych dla realizacji dostępu do systemu dla obsługi relacji B2B.

Specyfikacja usług. 1. Zakup usług informatycznych dla realizacji dostępu do systemu dla obsługi relacji B2B. W zawiązku z otrzymaniem dofinansowania na projekt: Zautomatyzowany system B2B elektronicznej wymiany dokumentów i danych, realizowany w ramach Programu Operacyjnego Innowacyjna Gospodarka, Działanie 8.2:Wspieranie

Bardziej szczegółowo

Szkolenia Systemy Krytyczne. www.cts.com.pl

Szkolenia Systemy Krytyczne. www.cts.com.pl Szkolenia Systemy Krytyczne www.cts.com.pl CO TO SĄ SYSTEMY KRYTYCZNE? Systemy wbudowane (albo: systemy kontrolne) = embedded systems (control systems), systemy krytyczne dla bezpieczeństwa = safety-critical

Bardziej szczegółowo

Sekcja I: Instytucja zamawiająca/podmiot zamawiający

Sekcja I: Instytucja zamawiająca/podmiot zamawiający Unia Europejska Publikacja Suplementu do Dziennika Urzędowego Unii Europejskiej 2, rue Mercier, 2985 Luxembourg, Luksemburg Faks: +352 29 29 42 670 E-mail: ojs@publications.europa.eu Informacje i formularze

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

Szablon Planu Testów Akceptacyjnych

Szablon Planu Testów Akceptacyjnych Szablon Planu Testów Akceptacyjnych strona 1 z 10 SPIS TREŚCI: 1 WPROWADZENIE 3 2 STRATEGIA TESTÓW AKCEPTACYJNYCH 4 2.1 Założenia do przeprowadzenia testów akceptacyjnych 4 2.1.1 Warunki przeprowadzenia

Bardziej szczegółowo

Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu. Projekt ZEFIR 2

Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu. Projekt ZEFIR 2 Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu Projekt ZEFIR 2 1 Metryka dokumentu Nazwa projektu Właściciel projektu Izba Celna Wykonawca* Produkt Autorzy Plik_wersja

Bardziej szczegółowo

KARTA PRZEDMIOTU. 1. NAZWA PRZEDMIOTU: Matematyka finansowa (MFI222) 2. KIERUNEK: MATEMATYKA. 3. POZIOM STUDIÓW: I stopnia

KARTA PRZEDMIOTU. 1. NAZWA PRZEDMIOTU: Matematyka finansowa (MFI222) 2. KIERUNEK: MATEMATYKA. 3. POZIOM STUDIÓW: I stopnia KARTA PRZEDMIOTU 1. NAZWA PRZEDMIOTU: Matematyka finansowa (MFI222) 2. KIERUNEK: MATEMATYKA 3. POZIOM STUDIÓW: I stopnia 4. ROK/ SEMESTR STUDIÓW: II/4 5. LICZBA PUNKTÓW ECTS: 8 6. LICZBA GODZIN: 30 / 30

Bardziej szczegółowo

Przyszłość to technologia

Przyszłość to technologia Przyszłość to technologia - twórz ją z nami Innowacyjne projekty dla prestiżowych klientów Wdrażamy jedne z największych w kraju projekty z dziedziny informatyki i nowoczesnych technologii. Realizujemy

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