PROJEKT SYSTEMU ZARZĄDZANIA W FIRMIE RADIX

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

Download "PROJEKT SYSTEMU ZARZĄDZANIA W FIRMIE RADIX"

Transkrypt

1 POLITECHNIKA GDAŃSKA WYDZIAŁ ZARZĄDZANIA I EKONOMII PRACA DYPLOMOWA magisterska PROJEKT SYSTEMU ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA W FIRMIE RADIX autor: inż. Adam Czarnecki promotor: dr inż. Cezary Orłowski Gdańsk, maj 2004

2

3 Spis treści 1. WSTĘP ANALIZA LITERATURY DEFINICJE, SKRÓTY I AKRONIMY NORMY DOTYCZĄCE ZARZĄDZANIA KONFIGURACJĄ I ICH PORÓWNANIE MODELE CYKLU ŻYCIA OPROGRAMOWANIA WNIOSKI Z ANALIZY LITERATURY ANALIZA STANU ISTNIEJĄCEGO PODSTAWOWE INFORMACJE O FIRMIE OFERTA OBECNE ROZWIĄZANIA I PROBLEMY W ZAKRESIE ZKO WNIOSKI Z ANALIZY STANU ISTNIEJĄCEGO SYSTEM ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT INFORMACJE OGÓLNE ORGANIZOWANIE ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA CZYNNOŚCI PRZY ZARZĄDZANIU KONFIGURACJĄ OPROGRAMOWANIA HARMONOGRAM ZKO ZASOBY ZKO DOBÓR NARZĘDZI CHARAKTERYSTYKA APLIKACJI DO ZKO KRYTERIA OCENY APLIKACJI ZKO WYNIKI OCENY PODSUMOWANIE BIBLIOGRAFIA SPIS RYSUNKÓW SPIS TABEL SPIS ZAŁĄCZNIKÓW I. Spis treści I

4

5 1. Wstęp Radix jest gdańską firmą powstałą w 1986 roku. Zajmuje się wytwarzaniem, wdrażaniem i szkoleniem w zakresie użytkowania oprogramowania dla administracji publicznej, głównie samorządów. Problemem podjętym w pracy są trudności firmy Radix z zarządzaniem konfiguracją przy dużej liczbie kolejnych wersji produkowanego oprogramowania oraz przy nowych warunkach pracy polegających na podziale konkretnych projektów pomiędzy kilku programistów. Celem pracy jest opracowanie projektu systemu zarządzania konfiguracją oprogramowania, który spełniłby oczekiwania firmy Radix, a także dobór narzędzi służących jego wdrożeniu. Podstawę dla powyższego ma stanowić analiza literatury i dotychczasowej praktyki firmy w zakresie opisywanego elementu zarządzania przedsięwzięciem informatycznym. Zaproponowane rozwiązanie oparto głównie na kaskadowym cyklu życia oprogramowania oraz normie ANSI/IEEE Std Odbiorcą wyników pracy jest firma Radix. 1. Wstęp 1

6 2. Analiza literatury W rozdziale tym przybliżone zostanie pojęcie zarządzania konfiguracją oprogramowania jako elementu zarządzania jakością w przedsięwzięciu informatycznym oraz terminów z nim związanych. Następnie przedstawione będą normy regulujące tworzenie planów zarządzania konfiguracją. Spośród nich wskazana zostanie jedna, najbardziej przydatna dla osiągnięcia celu pracy. Dalsza część rozdziału poświęcona będzie modelom cyklu życia oprogramowania ze wskazaniem najbardziej optymalnego z punktu widzenia zarządzania konfiguracją w firmie Radix. Norma wraz z modelem niczym wątek i osnowa powinny stworzyć przestrzeń dla projektu systemu Definicje, skróty i akronimy Poniżej zaprezentowano definicje pojęć związanych z zarządzaniem przedsięwzięciami informatycznymi, a kwestiami konfiguracji oprogramowania w szczególności, oraz skróty i akronimy z tym związane. W dalszej części pracy mogą znaleźć się informacje precyzujące i odnoszące definicje do specyfiki projektu Skróty i akronimy Skróty i akronimy używane w tej pracy: BSD Berkeley Software Distribution CPL Common Public License FTP File Transfer Protocol FZPB formularz zatwierdzania produktu bazowego FŻZ formularz żądania zmiany GNU GNU's Not Unix GPL General Public License GUI Graphics User Interface HTTP HyperText Transfer Protocol IP Internet Protocol JP jednostka programowa MPP metoda porównywania parami PB produkt bazowy PK pozycja konfiguracji PZK(O) plan zarządzania konfiguracją (oprogramowania) SWS specyfikacja wymagań systemowych 2. Analiza literatury 2

7 TCP ZK(O) ŻZ Transmission Control Protocol zarządzanie konfiguracją (oprogramowania) żądanie zmiany Definicje Zarządzanie konfiguracją (ZK) (ang. configuration management, CM) to dyscyplina stosująca techniczne i administracyjne wskazówki i nadzór w celu identyfikacji i dokumentacji fizycznych cech pozycji konfiguracji, kontroli nad zmianami tych cech, rejestracji i raportowania przebiegu zmian i statusu wdrażania oraz dla weryfikacji zgodności z określonymi wymaganiami [STSC 1999, s. 44]. Definicja [ANSI/IEEE Std ] podkreśla następujące aspekty ZK (rys. 2.1): identyfikację: schemat identyfikacji odzwierciedla strukturę produktu, rozróżnia składniki i ich typ, czyni je unikatowymi i dostępnymi w określonej postaci, kontrolę: kontrolowanie wydań (ang. release) produktu oraz jego zmian (poprawek i wersji) w cyklu życia oprogramowania poprzez nadzór w miejscu, które zapewnia spójność oprogramowania dzięki tworzeniu produktu stanowiącego podstawę odniesienia (produkt bazowy), rejestrowanie statusu (ang. status accounting): zapisywanie i raportowanie statusu składników i żądań zmian, gromadzenie istotnych statystyk o elementach składowych produktu, przegląd: sprawdzanie kompletności produktu i utrzymywanie spójności pomiędzy elementami składowymi poprzez zapewnienie, że produkt informatyczny jest poprawnie zbudowanym zbiorem elementów. ZARZĄDZANIE KONFIGURACJĄ OPROGRAMOWANIA Identyfikacja Kontrola zmian Rejestrowanie statusu Przeglądy Źródło: [STSC 1999, s. 10]. Rysunek 2.1 Elementy składowe zarządzania konfiguracją oprogramowania. W związku z istnieniem wielu platform środowiska programistycznego, zwiększającą się skalą przedsięwzięć informatycznych oraz równoległą pracą wielu zespołów 2. Analiza literatury 3

8 nad jednym projektem, postuluje się poszerzenie definicji ZK o następujące elementy [Brown, Dart i in. 1991, s. 3]: wytwarzanie: zarządzanie konstruowaniem i budową produktu w sposób efektywny i optymalny, zarządzanie procesami: zapewnienie wypełniania przez organizację procedur, założeń i stosowanie się do modelu cyklu życia, praca zespołowa: kontrola pracy i współdziałania pomiędzy wieloma użytkownikami produktu. Ta praca skupia się na zarządzaniu konfiguracją oprogramowania (ZKO) (ang. software configuration management, SCM). Stanowi ono mechanizm do identyfikowania, nadzorowania i śledzenia różnych wersji każdej jednostki programowej [PN- ISO , s. 21] na wszystkich etapach cyklu życia systemu informatycznego [STSC 1999, s. 10]. Pozycja konfiguracji (PK) (ang. configuration item, CI) to pojedynczy, możliwy do odseparowania komponent projektu lub produktu programistycznego [Subieta 2000, wykład 15, folia 5]. Zatem jest to wielkość atomowa z punktu widzenia ZKO. Jednostka programowa (JP) (ang. software item, SI) to dowolna część wyrobu programowego identyfikowana podczas pośredniego lub końcowego etapu opracowywania [PN-ISO , s. 5]. W niniejszej pracy przyjmuje się, że jednostka programowa jest szczególnym rodzajem pozycji konfiguracji. Produkt bazowy (PB) (ang. baseline) to pozycja konfiguracji oceniona i zaakceptowana formalnie przez odpowiednie ciało weryfikacyjne jako kompletna, stanowiąca podstawę do dalszych faz rozwoju projektu i której zmiana może być dokonana tylko poprzez odpowiednią procedurę kontroli zmiany [STSC 1999, s. 39]. Jedną z najwcześniej pojawiających się w przedsięwzięciu pozycji konfiguracji jest specyfikacja wymagań systemowych (SWS) (ang. System Requirements Specification, SRS). Ten dokument to część kontraktu pomiędzy klientem a wykonawcą, który stanowi podstawę dla projektu wytworzenia systemu i bazę, na której wykonawca szacuje koszt i czas trwania projektu [Górski 2000, s. 72]. Definicja zarządzania konfiguracją odwołuje się do pojęcia weryfikacji (ang. verification). W odniesieniu do oprogramowania oznacza ono proces oceny wyrobów danego etapu w celu zapewnienia prawidłowości i zgodności, w odniesieniu do wyro- 2. Analiza literatury 4

9 bów i norm dostarczonych jako dane wejściowe do tego etapu [PN-ISO , s. 5]. Walidacja, zatwierdzenie, atestowanie (w odniesieniu do oprogramowania) (ang. validation): to trzy nazwy procesu często idącego w parze z weryfikacją, a oznaczającego ocenę oprogramowania w celu zapewnienia zgodności z określonymi wymaganiami [PN-ISO , s. 5]. Na koniec warto wprowadzić pewne rozróżnienie między trzema zbliżonymi definicjami. Wydanie (ang. release) to pozycja konfiguracji przekazana na zewnątrz (zwykle na zewnątrz firmy wytwórcy oprogramowania); także czynność takiego przekazania [Subieta 2000, wykład 15, folia 20]. Pojęcie wydania jest zbliżone, lecz nie tożsame z terminami poprawka i wersja, gdyż poprawka (ang. revision) odnosi się zazwyczaj do zmienionej PK, a wersja (ang. version) do takiej poprawki, którą można uznać za znaczącą zmianę w stosunku do poprzedniej treści pozycji konfiguracji Normy dotyczące zarządzania konfiguracją i ich porównanie Jakkolwiek zarządzanie konfiguracją oprogramowania nie jest czynnością narzuconą firmom przez prawo, istnieją jednak normy ten obszar regulujące i zalecane do stosowania. Ogólną zaletą korzystania z norm w przypadku zarządzania konfiguracją jest łatwiejsza współpraca pomiędzy wieloma zespołami projektowymi z różnych firm, gdzie jednolity schemat ZK ułatwia czy wręcz umożliwia koordynowanie wspólnego projektu. Druga kwestia ma związek z opracowanym przez Instytut Inżynierii Oprogramowania Uniwersytetu Carnegie Mellon z Pittsburgha modelem oceny dojrzałości firmy informatycznej (ang. The Capability Maturity Model for Software, SW-CMM) [Paulk, Curtis i in. 1993]. Zgodnie z istniejącą w nim pięciostopniową gradacją, drugi stopień dojrzałości (tzw. powtarzalny, ang. repeatable) może osiągnąć to przedsiębiorstwo, które pośród wielu innych wymagań stosuje zarządzanie konfiguracją oprogramowania [Paulk, Curtis i in. 1993, s. 31], najlepiej zgodną z oficjalną normą. Pytanie brzmi: którą normę wybrać? Istnieje wiele norm dotyczących ZKO i różny jest zakres ich stosowania. Od norm wewnętrznych firm, przez branżowe (np. dla elektrowni atomowych [NUREG ]), po ogólnokrajowe i światowe. W niniejszym rozdziale przedstawione zostanie porównanie trzech amerykańskich norm [Bounds, Dart 1993]: 2. Analiza literatury 5

10 IEEE Standard for Software Configuration Management Plans [ANSI/IEEE Std ], NASA Software Configuration Management Plan Data Item Description [NASA Sfw DID ], DoD Software Development Plan Data Item Description (DID) w powiązaniu z DoD-STD-2167A [DoD DI-MCCS-80030A 1986]. O wyborze do porównania wyłącznie norm opracowanych w Stanach Zjednoczonych zadecydowały dwa powody. Po pierwsze, USA są liderem w zakresie rozwiązań informatycznych, zatem wypracowane w tym kraju tzw. dobre praktyki w zakresie inżynierii oprogramowania wydają się być najbardziej rozwinięte. Po drugie zaś, amerykańskie normy w odróżnieniu od, na przykład, europejskich są powszechnie dostępne i dzięki swojej popularności pozwalają zachować zgodność procedur pomiędzy różnymi wytwórcami oprogramowania, którzy mieliby w przyszłości współpracować. Wyrażając to mniej formalnie i przewrotnie, można napisać, że normy amerykańskie są powszechnie stosowane, gdyż posiadają najwięcej zalet, zaś jedną z największych jest ich powszechne stosowanie Kryteria porównania Jak zaznaczono, przedstawione w niniejszej pracy porównanie zostało dokonane przez Nadine M. Bounds i Susan A. Dart [1993]. Poniżej skrótowo przedstawione zostaną kryteria, jakie posłużyły autorkom do oceny trzech opisywanych norm. Nie przydzielono im żadnych wag, zatem przy przedstawionej później ocenie ich wpływ na wynik będzie taki sam Łatwość posługiwania się Pojęcie łatwości posługiwania się odnosi się do wymaganego wysiłku, jaki należy wnieść, by nauczyć się korzystać z normy oraz jaki konieczny jest przy kolejnym używaniu. Wśród cech opisywanego kryterium warto wskazać na przydatność normy dla osób o różnym stopniu doświadczenia w tworzeniu planów ZKO. Idealna byłaby norma, która potrafiłaby poprowadzić przez cały proces osobę mało lub wcale niedoświadczoną, a jednocześnie jej układ pozwalałby ekspertowi na szybki dostęp i wgląd do interesujących go zagadnień bez konieczności przeglądania całego dokumentu. Z wywiadu przeprowadzonego w firmie Radix wynika brak doświadczenia w stosowaniu procedur 2. Analiza literatury 6

11 ZKO, stąd warto zadbać, aby wprowadzający je dokument sam w sobie nie stanowił utrudnienia w korzystaniu Kompleksowość Za kompleksową należy uznać taka normę, która nie wymaga od korzystającego z niej zaglądania do innych źródeł ani proszenia innych o pomoc w trakcie opracowywania planu ZKO. Jest to dość ogólnikowe wyjaśnienie, zatem można rozszerzyć je wymieniając składniki, jakie obowiązkowo musi posiadać norma, by uznać ją za kompletną: opis części składowych planu ZK, a w szczególności: wprowadzenie i cel dokumentu, organizację ZK i podział kompetencji, identyfikację konfiguracji, kontrolę konfiguracji, rejestrowanie i raportowanie zmian w statusie konfiguracji, opis przeglądów/audytów konfiguracji w ZK, opis harmonogramów i kamieni milowych w ZK, jasno określony cel i odbiorców, czytelną, zwięzłą, prostą i sensowną zawartość, bez żadnych dwuznaczności. Listę można by oczywiście rozbudować o zalecenia o charakterze bardziej edytorskim niż merytorycznym [Bounds, Dart 1993, s ], jednak w tym miejscu zostaną one pominięte jako poboczne w stosunku do projektowanego systemu zarządzania konfiguracją oprogramowania Możliwość dopasowania Możliwość dopasowania oznacza, że normę można dostosowywać do potrzeb projektu. Minimum wymagań to: 2. Analiza literatury 7

12 możliwość usunięcia z planu elementu, który nie ma zastosowania w danym przedsięwzięciu, możliwość dowolnego kształtowania układu planu ZK, tak by jak najlepiej pasował do przedsięwzięcia. Cechy bardziej zaawansowanej normy to możliwość dostosowania jej do: każdego obszaru, jakiego dotyczy przedsięwzięcie informatyczne, dowolnego modelu lub fazy cyklu życia przedsięwzięcia, stosowania przy aplikacjach, sprzęcie i oprogramowaniu układowym (ang. firmware) Konsekwencja Normę można uznać za konsekwentną, jeśli nadano jej czytelną, jednolitą strukturę. Musi ona spełniać co najmniej poniższe warunki: standardowy format reprezentacji treści, standardowe nazewnictwo i posługiwanie się pojęciami, ten sam element ZK lub pojęcie nie są określane przez więcej niż jedną unikatową nazwę i nie są definiowane przez więcej niż jeden zestaw charakterystyk Poprawność Norma jest uważana za poprawną, gdy zawiera jedynie ważne i prawdziwe informacje. Wydawać by się mogło, że samo słowo norma wskazuje na dokument, który powinien wcześniej przejść przez procedurę weryfikacyjną wykluczającą istnienie jakichkolwiek niepoprawnych danych. Tak jest w przypadku norm krajowych lub branżowych, gdzie pisaniem norm zajmują się uznani eksperci, a i wiele szczebli musi pokonać dokument przed ostatecznym zatwierdzeniem. Jeśli jednak standard opracowywany jest wewnątrz firmy, nawet dużej, to może on posiadać formalne lub merytoryczne braki lub nieścisłości, które co prawda nie przeszkadzają osobom znającym stan faktyczny w jego stosowaniu w macierzystym przedsiębiorstwie, ale mogą utrudniać lub uniemożliwiać podążanie za wytycznymi przez osobę opierającą swoją wiedzę tylko na treści normy. Wskazując na minimalne wymagania wobec tego kryterium, stwierdza się, że norma jest poprawna, gdy: 2. Analiza literatury 8

13 nie zawiera żadnych błędnych informacji, nie zawiera żadnych sprzecznych informacji. Rozszerzając wymagania wobec normy, można żądać, aby: zawierała wyłącznie informacje niezbędne do zrozumienia tematu; niedostatek informacji zmusza użytkownika normy do poszukiwania informacji u innych źródeł; informacje zbędne lub zbyt rozbudowane, natomiast, utrudniają koncentrację na zagadnieniach naprawdę istotnych, zaproponowane w niej podejście miało sens zarówno z technicznego jak i praktycznego punktu widzenia Nawiązanie do cyklu życia Norma powinna wskazywać, jakie jest umiejscowienie planu ZKO w cyklu życia projektu informatycznego. Dodatkowym wymaganiem podnoszącym ocenę normy może być wskazywanie, jak do całego cyklu życia oprogramowania mają się poszczególne działania składowe ZK. Sześć wymienionych powyżej kryteriów odniesione zostanie do trójki norm, które uczestniczą w porównaniu. Zanim jednak przedstawiona zostanie ocena ilościowa, omówione zostaną mocne i słabe strony tych norm [Bounds, Dart 1993, s ] Norma dotycząca planu zarządzania konfiguracją oprogramowania IEEE Standard IEEE , będący uaktualnioną wersją normy z 1990 roku, nie powstał z myślą o żadnym konkretnym sektorze gospodarki, zatem jego zastosowanie jest uniwersalne. Kierowany jest do firm o różnym poziomie doświadczenia w zakresie ZKO, obejmuje cały cykl życia oprogramowania, uwzględnia współpracę z innymi organizacjami oraz różnice w stosowanym sprzęcie, a także inne czynności w obrębie projektu. Co więcej, nie jest ograniczony do żadnego określonego typu oprogramowania. Do zalet można także zaliczyć szczególną wagę, jaką przywiązuje standard IEEE do kontroli nad interfejsem (tj. powiązaniami z innymi elementami przedsięwzięcia informatycznego wykraczającymi poza zakres ZK) oraz podwykonawcami/dostawcami oraz szczegółową listę zagadnień, jakie należy wziąć pod rozwagę w każdym z kluczowych obszarów ZKO. 2. Analiza literatury 9

14 Innymi mocnymi stronami normy IEEE są: gruntowne podejście do każdego z elementów planu zarządzania konfiguracją, kompleksowość oraz odniesienie każdego z punktów do powiązanej z nią uzupełniającej normy będącej poradnikiem dobrego planowania ZKO [ANSI/IEEE ]. Pomimo wymienionych powyżej ogromnych zalet tego standardu, posiada on jednak kilka wad. Po pierwsze, nie przewiduje skorowidzu, który pozwoliłby czytelnikowi na sprawniejsze poruszanie się po dokumencie, jakim jest powstały w wyniku jego zastosowania plan ZKO. Nie jest to, oczywiście, uwaga merytoryczna, niemniej ten techniczny brak zmniejsza wygodę użytkowników dokumentu. Po drugie, norma nie zawiera przykładowego planu ZK czy nawet jego fragmentu. Standard wiele by zyskał, gdyby czytelnik mógł porównać przykład ze wskazówkami zawartymi w planie, a przynajmniej gdyby zawarto przykładowy diagram procesu kontroli zmiany, który to proces jest najtrudniejszy do zrozumienia i zaplanowania w całym ZKO. I wreszcie norma w niewielkim stopniu nawiązuje do cyklu życia oprogramowania, podczas gdy pożądane by było, aby wskazywała na związek cyklu z elementami ZK oraz pokazywała, jak czynności związane z zarządzaniem konfiguracją zmieniają się w poszczególnych fazach Opis elementu danych planu zarządzania konfiguracją oprogramowania NASA Norma amerykańskiej Narodowej Agencji do spraw Aeronautyki i Przestrzeni Kosmicznej [NASA Sfw DID ] powstała z myślą o określonym segmencie przemysłu. Ma ona dwie podstawowe zalety. Po pierwsze, jest uporządkowana i jednolita, dzięki czemu korzystanie z informacji w niej zawartych jest łatwe. Po drugie, niektóre składniki ZKO są opisane lepiej niż w dwóch pozostałych porównywanych normach. Są to: dokumentacja, formularz kontroli zmiany i zasoby. Norma traktuje dokumentację niezależnie od jednostek programowych w działach poświęconych identyfikacji oraz przechowywaniu i wydawaniu. Jest to swoiste przypomnienie dla użytkownika planu powstałego w wyniku stosowania normy, by pamiętał o odwoływaniu się do odpowiedniej dokumentacji. Norma uszczegóławia także dane, jakie zawierać powinien formularz kontroli zmiany, podczas gdy pozostałe standardy jedynie wspominają o konieczności istnienia takiego dokumentu. Rozróżniane są też przez normę takie zasoby jak: urządzenia, nośniki danych i ludzie. Niestety, można wskazać co najmniej kilka wad tej normy. Główną jest konieczność przygotowania oddzielnego planu ZK dla każdej jednostki programowej. 2. Analiza literatury 10

15 Wprowadza to ogromną nadmiarowość informacji, co komplikuje korzystanie z takiego planu w przeciętnej firmie. Można się domyślać, że dla NASA, której przedsięwzięcia obarczone są dużym ryzykiem i złożonością, takie rozwiązanie jest korzystne. Niemniej nie sprawdza się takie podejście w przypadku względnie niewielkich projektów. Jako drugi zarzut można wskazać mały stopień kompleksowości i szczegółowości opisywanej normy, przez co konieczne jest wspieranie się innymi dokumentami. Powierzchownie potraktowano m.in. kwestię identyfikacji pozycji konfiguracji. Ogólnie, osoba nie będąca ekspertem w zakresie zarządzania konfiguracją oprogramowanie nie jest w stanie skutecznie opracować planu ZKO bez odwoływania się do innych źródeł Opis elementu danych planu rozwoju oprogramowania Departamentu Obrony USA Norma ta [DoD DI-MCCS-80030A] powstała na potrzeby amerykańskiego Departamentu Obrony, niemniej pisano ją z myślą o możliwościach dostosowania do zmieniających się wymagań związanych z szybkim rozwojem technik informatycznych. Ma ona charakter swoistego przewodnika, a nie narzucanych z góry rozwiązań. Prócz wspomnianej zdolności do dopasowywania, norma ta posiada dwie główne zalety. Pierwsza z nich to możliwość włączenia planu ZKO do planu wytwarzania oprogramowania (ang. software development plan, SDP) lub traktowania jako osobnego dokumentu. Takie połączenie ma znaczenie wówczas, gdy ZK jest ściśle powiązane z zarządzaniem całym projektem oraz cyklem życia oprogramowania. Drugą z zalet jest dołączony przykładowy schemat działania kontroli nad konfiguracją, którą określono już wcześniej jako kluczową w całym planie ZK. Podobnie jak normie NASA, również dokumentowi Departamentu Obrony USA można zarzucić niewielki stopień kompleksowości i dogłębności, co każe wspierać się przy tworzeniu systemu ZK innymi opracowaniami. Inną wadą jest, co może z pozoru zaskakiwać, podatność na dopasowywanie. Chodzi o to, że ten zabieg może odbywać się jedynie poprzez rozbudowywanie planu względem opisywanej normy. Wymaga więc doświadczenia i wiedzy na temat elementów, o jakie należy plan wzbogacić. Poza tym norma DoD DI-MCCS-80030A dotyczy całego planu wytwarzania oprogramowania, którego zarządzanie konfiguracją jest tylko jedną z części. Do tego układ dokumentu sprawia, że bez przejrzenia całości, czytelnik nie dotrze do dwóch istotnych elementów ZK: do repozytorium rozwijanego oprogramowania oraz działań korygujących, które znajdują się poza rozdziałem poświęconym zarządzaniu konfiguracją. 2. Analiza literatury 11

16 Porównanie norm Tabela 2.1 ukazuje porównanie opisywanych norm pod kątem zaproponowanych w punkcie kryteriów. Tabela 2.1 Porównanie norm. Kryterium IEEE NASA DoD Łatwość posługiwania się Kompleksowość Możliwość dopasowania Konsekwencja Poprawność Nawiązanie do cyklu życia SUMA Źródło: [Bounds, Dart 1993, s. 16]. Jak widać, norma ANSI/IEEE Std uzyskała najlepszą ocenę w oczach autorów zestawienia. Na przydatność tej normy w praktyce firm informatycznych sektora MSP wskazują także Pacheco i Sanches [2000, s.3]. Również na tę normę, a nie na standard NASA, powołuje się Europejska Agencja Kosmiczna (ESA) w wydanym przez siebie przewodniku po zarządzaniu konfiguracją oprogramowania [ESA PSS ]. Cytowane porównanie nie jest jedynym. Zestawienie cech sześciu norm (w tym IEEE , poprzedniczki IEEE ) można znaleźć w wojskowym poradniku poświęconym ZKO [MIL-HDBK , załącznik F]. Nie zawiera on jednak oceny punktowej, ani nie wskazuje na najlepszą pod danym względem normę. Podobnie jest z porównaniem zamieszczonym w innej wojskowej publikacji, Software Configuration Management Technologies and Applications [STSC 1999, s. 23] Modele cyklu życia oprogramowania Proces zarządzania konfiguracją oprogramowania powinien być wpisany w cykl życia produktu programowego, albowiem w zależności od przyjętego modelu różnić się może rodzaj, kolejność i powiązanie między fazami cyklu. To zaś wpływa na strukturę ZKO, która niejako rozpięta jest na szkielecie wybranego modelu cyklu życia. W tym podrozdziale przedstawione zostaną najpopularniejsze modele cyklu życia oprogramowania oraz wskazany zostanie jeden, najbardziej optymalny pod względem przydatności w realiach firmy Radix Model kaskadowy Felix Redmill w [Górski 2000, s. 34] stwierdza, że zgodnie ze sztuką inżynierską projektowanie powinno poprzedzać realizację, a faza specyfikacji znajdować się na osi 2. Analiza literatury 12

17 czasu przed projektowaniem. Ten szereg zdarzeń jest punktem wyjścia do definicji modelu kaskadowego (ang. Waterfall Model). W tym modelu główne procesy projektu ukazane są jako etapy realizowane w ściśle zdefiniowanej kolejności, tak jak to ilustruje rys Nowy etap nie rozpocznie się, póki nie zakończy się jego poprzednik. Model przedstawiony na rysunku uwzględnia etap inicjalizacji (tu nazwany fazą strategiczną), często pomijany tam, gdzie kwestie zarządzania przedsięwzięciem nie znajdują zrozumienia w kierownictwie zespołu. Faza strategiczna Określenie wymagań Projektowanie Implementacja Integracja Testowanie Instalacja Konserwacja Źródło: [oprac. własne na podstawie: Jaszkiewicz 1997 i Pressman 2001]. Rysunek 2.2 Model kaskadowy. Model kaskadowy zakłada, że możliwe lub wręcz wskazane są iteracje, zarówno do etapu poprzedzającego jak i cofnięcie się do niemal samego początku, jakim jest określenie wymagań. Zaletą modelu kaskadowego jest łatwość zarządzania przedsięwzięciem na nim opartym. Natomiast jako wady wymienia się [Jaszkiewicz 1997, s. 17]: narzucenie twórcom oprogramowania ścisłej kolejności wykonywania prac, wysoki koszt błędów popełnionych we wstępnych fazach, długą przerwę w kontaktach z klientem. 2. Analiza literatury 13

18 Model V Podobnie jak model kaskadowy, model V definiuje główne procesy projektu jako etapy realizowane jeden po drugim (sekwencyjnie), przy czym rozpoczęcie kolejnego etapu jest uzależnione od zakończenia etapu poprzedniego. Sprzężone są z nim procesy weryfikacyjne i walidacyjne rozmieszczone na drugim ramieniu litery V, która obrazuje strukturę całego modelu jak pokazano na rysunku 2.3. Specyfikacja Projekt systemu Projekt podsystemu Projekt modułu Testowanie akceptacyjne Integracja i walidacja systemu Integracja i weryfikacja podsystemu Formalne testowanie modułu Kodowanie, wstępne testowanie modułu Źródło: [oprac. własne na podstawie: Górski 2000, s. 36]. Rysunek 2.3 Model V. Kolejne kroki procesu definiowania systemu (od specyfikacji rozpoczynając, na projekcie szczegółowym kończąc) umieszczone są coraz niżej na lewym ramieniu litery V. Po osiągnięciu dolnego punktu realizowane są kroki integracyjne umieszczone coraz wyżej na prawym ramieniu litery V, odpowiadające poszczególnym krokom znajdującym się na jej lewym ramieniu [Górski 2000, s ] Model przyrostowy W [Jaszkiewicz 1997, s.23] znajdujemy, że realizacja przyrostowa (ang. incremental development) rozpoczyna się od określenia wymagań (rys. 2.4) oraz wykonania wstępnego, ogólnego projektu całości systemu. Następnie wybierany jest pewien podzbiór funkcji systemu. Dalej, zgodnie z przebiegiem modelu kaskadowego, wykonywany jest szczegółowy projekt oraz implementacja części systemu realizującej te funkcje. Po przetestowaniu zrealizowany fragment pełnego systemu może zostać dostarczony klientowi. 2. Analiza literatury 14

19 Określenie wymagań Ogólny projekt Proces realizowany iteracyjnie Wybór podzbioru funkcji Szczegółowy projekt, implementacja i testy Dostarczenie zrealizowanej części systemu Źródło: [Jaszkiewicz 1997, s. 23]. Rysunek 2.4 Model przyrostowy. Zalety tego modelu to: skrócenie przerw w kontaktach z klientem, możliwość wczesnego wykorzystywania przez klienta dostarczonych fragmentów systemu. możliwość elastycznego reagowania na powstałe opóźnienia. Jeżeli realizacja fragmentu systemu opóźni się, nie musi to oznaczać opóźnienia całego przedsięwzięcia. Istnieje wtedy możliwość przyspieszenia prac nad dalszymi częściami. Wadą modelu przyrostowego jest pewien dodatkowy koszt związany z niezależną realizacją fragmentów systemu. Zazwyczaj nie ma możliwości wyodrębnienia podzbioru funkcji w pełni niezależnych od pozostałych. Toteż może zajść potrzeba implementacji tzw. szkieletów modułów, tj. modułów o interfejsie zgodnym z modułami, które znajdą się w pełnym systemie, lecz nie realizujących w pełni ich funkcji. 2. Analiza literatury 15

20 Model spiralny Jaszkiewicz [1997, s ] stwierdza, że bodaj najbardziej ogólnym modelem cyklu życia oprogramowania jest model spiralny zaproponowany przez Boehma w 1988 roku. Model ten (rys. 2.5) składa się z czterech głównych faz wykonywanych cyklicznie: Określenie celów ocena celów bieżącej fazy, definiowanie ograniczeń, wyznaczenie alternatywnych podejść do osiągnięcia tych celów. Analiza ryzyka rozważanie ogólnych opcji budowy nowej wersji systemu przy uwzględnieniu związanego z nimi ryzyka; faza ta może też obejmować budowę prototypu. Opracowanie i weryfikacja budowa kolejnej wersji systemu w sposób zgodny z modelem kaskadowym (por ) oraz ocena przez klienta; jeśli jest pozytywna, rozpoczyna się kolejny cykl. Planowanie ustalenie generalnych celów produkcji kolejnej wersji systemu. Skumulowany koszt Określenie celów, możliwości, ograniczeń Analiza ryzyka, ocena możliwości Uzgodnienie Planowanie następnej fazy Opracowanie, weryfikacja następnego produktu Źródło: [oprac. własne na podstawie: Beynon-Davies 1999, s. 77, Sikorski 2000, s. 37]. Rysunek 2.5 Model spiralny. Wadą wynikającą z konieczności tworzenia wielu modeli jest długi cykl wytwórczy. Zaletami modelu spiralnego są: iteracyjność oraz częste kontakty z klientem. 2. Analiza literatury 16

21 Wybór modelu Decydując się na wybór modelu cyklu życia programowania należy uwzględnić zalecenia literatury traktującej o ZKO i istniejącą praktykę firmy Radix. Z reguły pozycje literaturowe wymieniają wspomniane powyżej modele jako równorzędne w stosowaniu na potrzeby ZKO. Niemniej, zapewne ze względu na największą użyteczność, omawiany jest model kaskadowy. Autorzy jednego z opracowań [Futrtell, Shafer, Shafer 2002, s. 1215] dotyczących jakości w zarządzaniu przedsięwzięciami wpisują całość procesów ZKO w model kaskadowy. Natomiast bezpośredni wywiad w firmie Radix zakończył się stwierdzeniem jej przedstawiciela, że przedsięwzięcia realizowane są w oparciu o model spiralny. Zatem powstaje wrażenie, że projektant systemu zarządzania konfiguracją oprogramowania dla firmy Radix stoi przed dylematem, czy wybrać model kaskadowy, w który stosunkowo łatwo wpisać procedury ZKO, czy też pozostać przy modelu spiralnym, by jak najmniej odchodzić od wymagań firmy. Tak naprawdę dylemat jest pozorny. Model spiralny to w rzeczywistości model kaskadowy poszerzony o zagadnienia zarządzania projektem, głównie zaś o analizę ryzyka. Widać to dobrze na rysunku 2.5, gdzie przecinająca spiralę strzałka ukazuje przebieg modelu kaskadowego. Jako że ZKO dotyczy zagadnień przedstawionych w ćwiartce poświęconej opracowywaniu produktu (to tam powstają i są zmieniane pozycje konfiguracji), można zawęzić zagadnienie ZKO w modelu spiralnym do podejścia kaskadowego. Zatem ze względu na przejrzystą strukturę, odniesienie w literaturze traktującej o ZKO i współgranie z wymaganiami samej firmy wybiera się model kaskadowy jako zalecany przy tworzeniu systemu zarządzania konfiguracją oprogramowania dla potrzeb firmy Radix Wnioski z analizy literatury Zgodnie z tym, co zaznaczono na początku rozdziału, zarządzanie konfiguracją oprogramowania jest elementem zarządzania jakością, a dokładniej zapewnienia jakości. Podejściem ułatwiającym stosowanie ZKO w przedsięwzięciach informatycznych jest stosowanie zaleceń w postaci normy. Jako najbardziej przydatną dla tworzonego w tej pracy projektu wybrano normę ANSI/IEEE Std ze względu na możliwość dość dobrego dopasowania do potrzeb niewielkiej firmy, jaką jest Radix. Porównując ją z pozostałymi dwiema nie moż- 2. Analiza literatury 17

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

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA numer wersji

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

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

Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób

Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób Personalizacja Plan-de-CAMpagne dostosowywanie programu do indywidualnych potrzeb firm, działów oraz osób Wdrożenie systemu planowania zasobów przedsiębiorstwa pomimo wielu korzyści często też wiąże się

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

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

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny Cel: Opracowanie szczegółowych zaleceń i procedur normujących pracę działu wytwarzania oprogramowania w przedsiębiorstwie

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

Zmiany wymagań normy ISO 14001

Zmiany wymagań normy ISO 14001 Zmiany wymagań normy ISO 14001 Międzynarodowa Organizacja Normalizacyjna (ISO) opublikowała 15 listopada br. zweryfikowane i poprawione wersje norm ISO 14001 i ISO 14004. Od tego dnia są one wersjami obowiązującymi.

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

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

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

Dokument Detaliczny Projektu

Dokument Detaliczny Projektu Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej

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

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

Inżynieria oprogramowania I

Inżynieria oprogramowania I Kontakt Inżynieria I Andrzej Jaszkiewicz Andrzej Jaszkiewicz p. 424y, Piotrowo 3a tel. 66 52 371 jaszkiewicz@cs.put.poznan.pl www-idss.cs.put.poznan.pl/~jaszkiewicz Literatura A. Jaszkiewicz, Inżynieria,

Bardziej szczegółowo

ŚCIEŻKA: Zarządzanie projektami

ŚCIEŻKA: Zarządzanie projektami ŚCIEŻKA: Zarządzanie projektami Ścieżka dedykowana jest każdej osobie, która chce rozwijać siebie i swoją organizację - w szczególności: Kadrze menedżerskiej i kierowniczej przedsiębiorstw Kierownikom

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

Nie o narzędziach a o rezultatach. czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT. Władysławowo, 6 października 2011 r.

Nie o narzędziach a o rezultatach. czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT. Władysławowo, 6 października 2011 r. Nie o narzędziach a o rezultatach czyli skuteczny sposób dokonywania uzgodnień pomiędzy biznesem i IT Władysławowo, 6 października 2011 r. Dlaczego taki temat? Ci którzy wykorzystują technologie informacyjne

Bardziej szczegółowo

PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT WERSJA

PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.6 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT WERSJA

Bardziej szczegółowo

SKZ System Kontroli Zarządczej

SKZ System Kontroli Zarządczej SKZ System Kontroli Zarządczej KOMUNIKAT Nr 23 MINISTRA FINANSÓW z dnia 16 grudnia 2009 r. w sprawie standardów kontroli zarządczej dla sektora finansów publicznych Na podstawie art. 69 ust. 3 ustawy z

Bardziej szczegółowo

OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA

OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA OPROGRAMOWANIE WSPOMAGAJĄCE ZARZĄDZANIE PROJEKTAMI. PLANOWANIE ZADAŃ I HARMONOGRAMÓW. WYKRESY GANTTA Projekt to metoda na osiągnięcie celów organizacyjnych. Jest to zbiór powiązanych ze sobą, zmierzających

Bardziej szczegółowo

Inżynieria Oprogramowania. Inżynieria Oprogramowania 1/36

Inżynieria Oprogramowania. Inżynieria Oprogramowania 1/36 Inżynieria Oprogramowania Inżynieria Oprogramowania 1/36 Inżynieria Oprogramowania 2/36 Literatura 1. Gamma E. i in.: Wzorce projektowe, WNT, Warszawa 2005 2. Jaszkiewicz A.: Inżynieria oprogramowania,

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

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

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski Autor: Artur Lewandowski Promotor: dr inż. Krzysztof Różanowski Przegląd oraz porównanie standardów bezpieczeństwa ISO 27001, COSO, COBIT, ITIL, ISO 20000 Przegląd normy ISO 27001 szczegółowy opis wraz

Bardziej szczegółowo

Informacje o wybranych funkcjach systemu klasy ERP Realizacja procedur ISO 9001

Informacje o wybranych funkcjach systemu klasy ERP Realizacja procedur ISO 9001 iscala Informacje o wybranych funkcjach systemu klasy ERP Realizacja procedur ISO 9001 Opracował: Grzegorz Kawaler SCALA Certified Consultant Realizacja procedur ISO 9001 1. Wstęp. Wzrastająca konkurencja

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

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Modelowanie biznesowe jest stykiem między

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

Wymagania edukacyjne z informatyki dla klasy szóstej szkoły podstawowej.

Wymagania edukacyjne z informatyki dla klasy szóstej szkoły podstawowej. Wymagania edukacyjne z informatyki dla klasy szóstej szkoły podstawowej. Dział Zagadnienia Wymagania podstawowe Wymagania ponadpodstawowe Arkusz kalkulacyjny (Microsoft Excel i OpenOffice) Uruchomienie

Bardziej szczegółowo

10. Dokumentacja systemu zarządzania bezpieczeństwem i higieną pracy

10. Dokumentacja systemu zarządzania bezpieczeństwem i higieną pracy 10. Dokumentacja systemu zarządzania bezpieczeństwem i higieną pracy 10.1. Co to są dokumenty i zapisy w systemie zarządzania bezpieczeństwem i higieną pracy? W każdym systemie zarządzania dokumentacja

Bardziej szczegółowo

Załącznik nr 2 do Umowy nr... z dnia... Zawartość Planu Jakości Projektu i wymagania w zakresie jego aktualizacji

Załącznik nr 2 do Umowy nr... z dnia... Zawartość Planu Jakości Projektu i wymagania w zakresie jego aktualizacji Załącznik nr 2 do Umowy nr... z dnia... Zawartość Planu Jakości Projektu i wymagania w zakresie jego aktualizacji I. Zawartość Planu Jakości Projektu 1. Wstęp 1.1. Cel Planu Jakości Projektu 1.2. Zastosowanie

Bardziej szczegółowo

PROCEDURA. Nadzór nad dokumentami i zapisami

PROCEDURA. Nadzór nad dokumentami i zapisami I. Cel działania Celem procedury jest określenie zasad postępowania z dokumentacją SZJ i jakości zapewniających: 1) zgodność dokumentacji SZJ z obowiązującym prawem i wymaganiami; 2) formalną i merytoryczną

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

Procedura Walidacyjna Interfejs

Procedura Walidacyjna Interfejs Strona: 1 Stron: 7 SPIS TREŚCI: 1. CEL 2. ZAKRES 3. DEFINICJE 4. ODPOWIEDZIALNOŚĆ I UPRAWNIENIA 5. TRYB POSTĘPOWANIA 6. ZAŁĄCZNIKI Podlega aktualizacji X Nie podlega aktualizacji Strona: 2 Stron: 7 1.

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

Szablon i zasady pisana pracy dyplomowej. Aneta Poniszewska-Marańda

Szablon i zasady pisana pracy dyplomowej. Aneta Poniszewska-Marańda Szablon i zasady pisana pracy dyplomowej Aneta Poniszewska-Marańda Spis treści Spis treści powinien zawierać spis wszystkich rozdziałów oraz podrozdziałów wraz z numerami stron, na których się rozpoczynają

Bardziej szczegółowo

ECDL/ICDL Zarządzanie projektami Moduł S5 Sylabus - wersja 1.0

ECDL/ICDL Zarządzanie projektami Moduł S5 Sylabus - wersja 1.0 ECDL/ICDL Zarządzanie projektami Moduł S5 Sylabus - wersja 1.0 Przeznaczenie Sylabusa Dokument ten zawiera szczegółowy Sylabus dla modułu ECDL/ICDL Zarządzanie projektami. Sylabus opisuje zakres wiedzy

Bardziej szczegółowo

Zacznijmy więc pracę z repozytorium. Pierwsza konieczna rzecz do rozpoczęcia pracy z repozytorium, to zalogowanie się w serwisie:

Zacznijmy więc pracę z repozytorium. Pierwsza konieczna rzecz do rozpoczęcia pracy z repozytorium, to zalogowanie się w serwisie: Repozytorium służy do przechowywania plików powstających przy pracy nad projektami we w miarę usystematyzowany sposób. Sam mechanizm repozytorium jest zbliżony do działania systemu plików, czyli składa

Bardziej szczegółowo

Zmiany w standardzie ISO dr inż. Ilona Błaszczyk Politechnika Łódzka

Zmiany w standardzie ISO dr inż. Ilona Błaszczyk Politechnika Łódzka Zmiany w standardzie ISO 9001 dr inż. Ilona Błaszczyk Politechnika Łódzka 1 W prezentacji przedstawiono zmiany w normie ISO 9001 w oparciu o projekt komitetu. 2 3 4 5 6 Zmiany w zakresie terminów używanych

Bardziej szczegółowo

Zarządzanie Jakością. System jakości jako narzędzie zarządzania przedsiębiorstwem. Dr Mariusz Maciejczak

Zarządzanie Jakością. System jakości jako narzędzie zarządzania przedsiębiorstwem. Dr Mariusz Maciejczak Zarządzanie Jakością System jakości jako narzędzie zarządzania przedsiębiorstwem Dr Mariusz Maciejczak SYSTEM System to zespół powiązanych ze sobą elementów, które stanowią pewną całość. Istotną cechą

Bardziej szczegółowo

"Projektowanie - wdrożenie - integracja - uruchomienie, czyli jak skutecznie zrealizować projekt inwestycyjny".

Projektowanie - wdrożenie - integracja - uruchomienie, czyli jak skutecznie zrealizować projekt inwestycyjny. "Projektowanie - wdrożenie - integracja - uruchomienie, czyli jak skutecznie zrealizować projekt inwestycyjny". CZYNNIKI PROJEKTU Cel (zakres) projektu: wyznacza ramy przedsięwzięcia, a tym samym zadania

Bardziej szczegółowo

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym

Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM

Bardziej szczegółowo

Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach)

Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach) Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach) 1. Wstęp: 1.1. Cel. Niniejszy dokument przestawia specyfikację wymagań systemowych (zarówno funkcjonalnych jak i niefunkcjonalnych)

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

...Gospodarka Materiałowa

...Gospodarka Materiałowa 1 Gospodarka Materiałowa 3 Obsługa dokumentów magazynowych 4 Ewidencja stanów magazynowych i ich wycena 4 Inwentaryzacja 4 Definiowanie indeksów i wyrobów 5 Zaopatrzenie magazynowe 5 Kontrola jakości 5

Bardziej szczegółowo

Metodologia weryfikacji wymagań IRIS w obszarze Projektowania i Rozwoju w teorii i praktyce. Szymon Wapienik TUV NORD Polska

Metodologia weryfikacji wymagań IRIS w obszarze Projektowania i Rozwoju w teorii i praktyce. Szymon Wapienik TUV NORD Polska Metodologia weryfikacji wymagań IRIS w obszarze Projektowania i Rozwoju w teorii i praktyce Szymon Wapienik TUV NORD Polska WARSZTATY SIRTS Metodologia weryfikacji wymagań IRIS Warszawa 25 listopada 2009r.

Bardziej szczegółowo

Ogranicz listę klasyfikacji budżetowych do powiązanych z danym kontem księgowym

Ogranicz listę klasyfikacji budżetowych do powiązanych z danym kontem księgowym Zależności i kontrola danych budżetowych w systemie Sz@rk FK 1. Wstęp Począwszy od wersji Sz@rk FK 2011 (11.03.30) wprowadzono do programu finansowoksięgowego nowe możliwości dotyczące kontrolowania poprawności

Bardziej szczegółowo

PLAN DZIAŁANIA KT 204 ds. Rysunku Technicznego i Dokumentacji Technicznej

PLAN DZIAŁANIA KT 204 ds. Rysunku Technicznego i Dokumentacji Technicznej Strona 1 PLAN DZIAŁANIA KT 204 ds. Rysunku Technicznego i Dokumentacji Technicznej STRESZCZENIE Komitet Techniczny nr 204 ds. Rysunku Technicznego i Dokumentacji Technicznej, działający w ramach Polskiego

Bardziej szczegółowo

2) stosowane metody i środki uwierzytelnienia oraz procedury związane z ich zarządzaniem i użytkowaniem,

2) stosowane metody i środki uwierzytelnienia oraz procedury związane z ich zarządzaniem i użytkowaniem, Wskazówki dotyczące sposobu opracowania instrukcji określającej sposób zarządzania systemem informatycznym, służącym do przetwarzania danych osobowych, ze szczególnym uwzględnieniem wymogów bezpieczeństwa

Bardziej szczegółowo

Tomasz Grześ. Systemy zarządzania treścią

Tomasz Grześ. Systemy zarządzania treścią Tomasz Grześ Systemy zarządzania treścią Co to jest CMS? CMS (ang. Content Management System System Zarządzania Treścią) CMS definicje TREŚĆ Dowolny rodzaj informacji cyfrowej. Może to być np. tekst, obraz,

Bardziej szczegółowo

Szczegółowy Opis Przedmiotu Zamówienia

Szczegółowy Opis Przedmiotu Zamówienia MINISTERSTWO ADMINISTRACJI i CYFRYZACJI Warszawa, dnia 04 kwietnia 2014 r. DEPARTAMENT FUNDUSZY STRUKTURALNYCH Szczegółowy Opis Przedmiotu Zamówienia I. Wstęp Program Operacyjny Innowacyjna Gospodarka

Bardziej szczegółowo

SHAREPOINT SHAREPOINT QM SHAREPOINT DESINGER SHAREPOINT SERWER. Opr. Barbara Gałkowska

SHAREPOINT SHAREPOINT QM SHAREPOINT DESINGER SHAREPOINT SERWER. Opr. Barbara Gałkowska SHAREPOINT SHAREPOINT QM SHAREPOINT DESINGER SHAREPOINT SERWER Opr. Barbara Gałkowska Microsoft SharePoint Microsoft SharePoint znany jest również pod nazwą Microsoft SharePoint Products and Technologies

Bardziej szczegółowo

Przedsięwzięcia Informatyczne w Zarządzaniu

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

Bardziej szczegółowo

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

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

CRM VISION FUNKCJE SYSTEMU

CRM VISION FUNKCJE SYSTEMU www.crmvision.pl CRM VISION FUNKCJE SYSTEMU www.crmvision.pl CRM VISION FUNKCJE SYSTEMU CRM Vision to nowoczesne, bezpieczne oprogramowanie wspomagające zarządzanie firmą poprzez usprawnienie przepływu

Bardziej szczegółowo

Metodyka zarządzania ryzykiem w obszarze bezpieczeństwa informacji

Metodyka zarządzania ryzykiem w obszarze bezpieczeństwa informacji 2012 Metodyka zarządzania ryzykiem w obszarze bezpieczeństwa informacji Niniejszy przewodnik dostarcza praktycznych informacji związanych z wdrożeniem metodyki zarządzania ryzykiem w obszarze bezpieczeństwa

Bardziej szczegółowo

Ćwiczenie 1. System jakości w laboratorium oceny żywności

Ćwiczenie 1. System jakości w laboratorium oceny żywności Ćwiczenie 1. System jakości w laboratorium oceny żywności Powszechnie przyjmuje się, że każde laboratorium, które chce reprezentować wiarygodne dane musi wdrożyć odpowiednie procedury zapewnienia jakości.

Bardziej szczegółowo

Szkolenie Stowarzyszenia Polskie Forum ISO 14000 Zmiany w normie ISO 14001 i ich konsekwencje dla organizacji Warszawa, 16.04.2015

Szkolenie Stowarzyszenia Polskie Forum ISO 14000 Zmiany w normie ISO 14001 i ich konsekwencje dla organizacji Warszawa, 16.04.2015 Wykorzystanie elementów systemu EMAS w SZŚ według ISO 14001:2015 dr hab. inż. Alina Matuszak-Flejszman, prof. nadzw. UEP Agenda Elementy SZŚ według EMAS (Rozporządzenie UE 1221/2009) i odpowiadające im

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

Dopasowanie IT/biznes

Dopasowanie IT/biznes Dopasowanie IT/biznes Dlaczego trzeba mówić o dopasowaniu IT-biznes HARVARD BUSINESS REVIEW, 2008-11-01 Dlaczego trzeba mówić o dopasowaniu IT-biznes http://ceo.cxo.pl/artykuly/51237_2/zarzadzanie.it.a.wzrost.wartosci.html

Bardziej szczegółowo

PLAN WDROśENIA SYSTEMU PROJEKT WERSJA

PLAN WDROśENIA SYSTEMU PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.3 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN WDROśENIA SYSTEMU PROJEKT WERSJA numer wersji

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

produkować, promować i sprzedawać produkty, zarządzać i rozliczać przedsięwzięcia, oraz komunikować się wewnątrz organizacji.

produkować, promować i sprzedawać produkty, zarządzać i rozliczać przedsięwzięcia, oraz komunikować się wewnątrz organizacji. Wspieramy w doborze, wdrażaniu oraz utrzymaniu systemów informatycznych. Od wielu lat dostarczamy technologie Microsoft wspierające funkcjonowanie działów IT, jak i całych przedsiębiorstw. Nasze oprogramowanie

Bardziej szczegółowo

Zastosowanie symulacji Monte Carlo do zarządzania ryzykiem przedsięwzięcia z wykorzystaniem metod sieciowych PERT i CPM

Zastosowanie symulacji Monte Carlo do zarządzania ryzykiem przedsięwzięcia z wykorzystaniem metod sieciowych PERT i CPM SZKOŁA GŁÓWNA HANDLOWA w Warszawie STUDIUM MAGISTERSKIE Kierunek: Metody ilościowe w ekonomii i systemy informacyjne Karol Walędzik Nr albumu: 26353 Zastosowanie symulacji Monte Carlo do zarządzania ryzykiem

Bardziej szczegółowo

PROCEDURA. Monitorowanie i aktualizacja planów strategicznych

PROCEDURA. Monitorowanie i aktualizacja planów strategicznych I. Cel działania Celem niniejszej procedury jest zapewnienie, iż działania związane z zarządzaniem Miastem odbywają się w sposób planowy, zgodny z przyjętą Strategią rozwoju społeczno-gospodarczego Miasta

Bardziej szczegółowo

Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania

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

Bardziej szczegółowo

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

Promotor: dr inż. Krzysztof Różanowski

Promotor: dr inż. Krzysztof Różanowski Warszawska Wyższa Szkoła Informatyki Prezentacja do obrony pracy dyplomowej: Wzorcowa polityka bezpieczeństwa informacji dla organizacji zajmującej się testowaniem oprogramowania. Promotor: dr inż. Krzysztof

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

Normalizacja baz danych

Normalizacja baz danych Normalizacja baz danych Definicja 1 1 Normalizacja to proces organizowania danych w bazie danych. Obejmuje to tworzenie tabel i ustanawianie relacji między tymi tabelami zgodnie z regułami zaprojektowanymi

Bardziej szczegółowo

Biblioteki publiczne

Biblioteki publiczne Instrukcja pracy w programie do gromadzenia danych statystycznych w ramach projektu Analiza Funkcjonowania Bibliotek Biblioteki publiczne Spis treści 1. Użytkownicy i uprawnienia 1 2. Logowanie/rejestracja

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

Strona tytułowa, zgodnie z wymaganiami zamieszczonymi na stronie www uczelni. Wzór strony dostępny jest w dzienniku wirtualnym - 1 -

Strona tytułowa, zgodnie z wymaganiami zamieszczonymi na stronie www uczelni. Wzór strony dostępny jest w dzienniku wirtualnym - 1 - Strona tytułowa, zgodnie z wymaganiami zamieszczonymi na stronie www uczelni. Wzór strony dostępny jest w dzienniku wirtualnym - 1 - Spis treści 1 Wstęp... 3 1.1 Cel pracy... 3 1.2 Układ pracy... 4 2 Podstawy

Bardziej szczegółowo

1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem.

1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem. 1/ Nazwa zadania: Dostawa, wdrożenie i serwis informatycznego systemu zarządzania projektami dla Urzędu Miejskiego Wrocławia wraz ze szkoleniem. 2/ Wykonawcy: Konsorcjum: Netline Group wraz z Premium Technology

Bardziej szczegółowo

WYTYCZNE OPRACOWYWANIA PROCEDUR

WYTYCZNE OPRACOWYWANIA PROCEDUR Strona 1/6 WYTYCZNE OPRACOWYWANIA PROCEDUR 1. Procedura - zasady ogólne Procedura systemu zarządzania jakością określa: Cele i zakres działania Co powinno być zrobione i przez kogo Kiedy, gdzie i w jaki

Bardziej szczegółowo

Plan Komunikacji projektu samooceny CAF. Gminy Zapolice. Zapolice, lipiec 2011

Plan Komunikacji projektu samooceny CAF. Gminy Zapolice. Zapolice, lipiec 2011 1 Plan Komunikacji projektu samooceny CAF Gminy Zapolice Zapolice, lipiec 2011 1 2 SPIS TREŚCI: str. Wprowadzenie... 3 1. Projekt wdrożenia metody CAF w Urzędzie... 3 2. Plan komunikacji uczestników wdrożenia

Bardziej szczegółowo

INSTRUKCJA ZARZĄDZANIA PROJEKTAMI STRATEGICZNYMI

INSTRUKCJA ZARZĄDZANIA PROJEKTAMI STRATEGICZNYMI Załącznik Nr 2 do Zarządzenia Nr 52/2014 Rektora UMCS INSTRUKCJA ZARZĄDZANIA PROJEKTAMI STRATEGICZNYMI Spis treści Słownik pojęć... 1 Cz. 1 Inicjatywy Projektów Strategicznych... 2 Cz. 2 Realizacja Projektów

Bardziej szczegółowo

Zarządzanie projektami IT

Zarządzanie projektami IT Zarządzanie projektami IT Źródła Zarządzanie projektami, J. Betta, Politechnika Wrocławska, 2011 Zarządzanie projektami IT, P. Brzózka, CuCamp, styczeń 2011 Zarządzanie projektami IT w przedsiębiorstwie

Bardziej szczegółowo

Dokument Detaliczny Projektu

Dokument Detaliczny Projektu Dokument Detaliczny Projektu Dla Biblioteki miejskiej Wersja 1.0 Streszczenie Niniejszy dokument detaliczny projektu(ddp) przedstawia szczegóły pracy zespołu projektowego, nad stworzeniem aplikacji bazodanowej

Bardziej szczegółowo

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot Inżynieria Programowania Inżynieria Arkadiusz Chrobot Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 20 października 2015 Plan wykładu 1. Wstęp 2. Studium wykonywalności 3. Określanie

Bardziej szczegółowo

Webowy generator wykresów wykorzystujący program gnuplot

Webowy generator wykresów wykorzystujący program gnuplot Uniwersytet Mikołaja Kopernika Wydział Fizyki, Astronomii i Informatyki Stosowanej Marcin Nowak nr albumu: 254118 Praca inżynierska na kierunku informatyka stosowana Webowy generator wykresów wykorzystujący

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

Jak wdrożyć CRM w małej i średniej firmie? Dariusz Mazur, Madar

Jak wdrożyć CRM w małej i średniej firmie? Dariusz Mazur, Madar Jak wdrożyć CRM w małej i średniej firmie? Dariusz Mazur, Madar Plan wystąpienia Podstawowe definicje System informatyczny dla MSP Pięć kroków udanego wdrożenia Podsumowanie Co to jest CRM Posiadanie takiej

Bardziej szczegółowo

ISO Matrix - e-iso dla Twojej firmy

ISO Matrix - e-iso dla Twojej firmy ISO Matrix - e-iso dla Twojej firmy Dlaczego platforma IT? Nasi klienci, którym wdrażamy Systemy Zarządzania ISO, to głównie małe i średnie przedsiębiorstwa. Czy rzeczywiście zastosowanie platformy informatycznej

Bardziej szczegółowo

System kontroli wersji - wprowadzenie. Rzeszów,2 XII 2010

System kontroli wersji - wprowadzenie. Rzeszów,2 XII 2010 System kontroli wersji - wprowadzenie Rzeszów,2 XII 2010 System kontroli wersji System kontroli wersji (ang. version/revision control system) służy do śledzenia zmian głównie w kodzie źródłowym oraz pomocy

Bardziej szczegółowo

Case Study. aplikacji Microsoft Dynamics CRM 4.0. Wdrożenie w firmie Finder S.A.

Case Study. aplikacji Microsoft Dynamics CRM 4.0. Wdrożenie w firmie Finder S.A. Case Study aplikacji Microsoft Dynamics CRM 4.0 Wdrożenie w firmie Finder S.A. PRZEDSTAWIENIE FIRMY Finder jest operatorem systemu lokalizacji i monitoringu, wspomagającego zarządzanie pracownikami w terenie

Bardziej szczegółowo

ROZPORZĄDZENIE DELEGOWANE KOMISJI (UE) NR

ROZPORZĄDZENIE DELEGOWANE KOMISJI (UE) NR 28.5.2014 L 159/41 ROZPORZĄDZENIA ROZPORZĄDZENIE DELEGOWANE KOMISJI (UE) NR 574/2014 z dnia 21 lutego 2014 r. zmieniające załącznik III do rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 305/2011

Bardziej szczegółowo

Funkcjonalność jest zgrupowana w następujących obszarach:

Funkcjonalność jest zgrupowana w następujących obszarach: Human Resources Funkcjonalność jest zgrupowana w następujących obszarach: Płace i Kadry System ocen pracowników/pulpit pracownika Informacje pracownicze Podzielnik Karty pracy RCP (Rejestracja Czasu Pracy)

Bardziej szczegółowo

2.3 Jakie procesy zarządzanie bezpieczeństwem i higieną pracy można zidentyfikować i opisać w przedsiębiorstwie?

2.3 Jakie procesy zarządzanie bezpieczeństwem i higieną pracy można zidentyfikować i opisać w przedsiębiorstwie? 2.3 Jakie procesy zarządzanie bezpieczeństwem i higieną pracy można zidentyfikować i opisać w przedsiębiorstwie? Zastosowanie podejścia procesowego sprowadza się do trzech podstawowych etapów (Rys. 5),

Bardziej szczegółowo

System zarządzania zleceniami

System zarządzania zleceniami Verlogic Systemy Komputerowe 2013 Wstęp Jednym z ważniejszych procesów występujących w większości przedsiębiorstw jest sprawna obsługa zamówień klientów. Na wspomniany kontekst składa się: przyjęcie zlecenia,

Bardziej szczegółowo

Załącznik do zarządzenia nr 29/2005/2006 Obowiązuje od 23.06.2006 r. POLITYKA BEZPIECZEŃSTWA

Załącznik do zarządzenia nr 29/2005/2006 Obowiązuje od 23.06.2006 r. POLITYKA BEZPIECZEŃSTWA Załącznik do zarządzenia nr 29/2005/2006 Obowiązuje od 23.06.2006 r. POLITYKA BEZPIECZEŃSTWA ZESPÓŁ SZKÓŁ PLASTYCZNYCH W DĄBROWIE GÓRNICZEJ CZĘŚĆ OGÓLNA Podstawa prawna: 3 i 4 rozporządzenia Ministra Spraw

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

2.11. Monitorowanie i przegląd ryzyka 2.12. Kluczowe role w procesie zarządzania ryzykiem

2.11. Monitorowanie i przegląd ryzyka 2.12. Kluczowe role w procesie zarządzania ryzykiem Spis treści Wstęp 1. Wprowadzenie 1.1. Co to jest bezpieczeństwo informacji? 1.2. Dlaczego zapewnianie bezpieczeństwa informacji jest potrzebne? 1.3. Cele, strategie i polityki w zakresie bezpieczeństwa

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