Politechnika Koszalińska Wydział Informatyki i Elektroniki Zarządzanie projektami informatycznymi Projekt aplikacji wspomagającej zarządzanie działalnością gabinetu lekarskiego o rozszerzonej funkcjonalności. Autor: Jan Łukowicz Studia magisterskie uzupełniające, semestr drugi 2009 r.
Spis treści Plan projektu... 4 Cel główny... 4 Cele dodatkowe... 4 Charakterystyka problemu... 4 Beneficjenci projektu... 4 Efekty od zakończenia prac projektowych (wyniki, wpływy)... 4 Zadania do wykonania... 4 Czas i zasięg zadań... 4 Sposoby ewaluacji zadań... 5 Kontynuacja projektu... 5 Metoda punktów funkcyjnych... 6 Lista kontrolna ryzyka... 7 Analiza ryzyka projektu... 10 Zarządzanie jakością... 12
Plan projektu Cel główny Zmniejszenie nakładu pracy, potrzebnego do zarządzania działalnością gabinetu lekarskiego. Cele dodatkowe Lepsze zabezpieczenie i archiwizacja dokumentacji medycznej. Ułatwienie planowania czasu pracy personelu gabinetu. Charakterystyka problemu Dzisiejszy sposób zarządzania gabinetem lekarskim jest mało efektywny z kilku powodów: przy dużej liczbie lekarzy występuje problem z podziałem pracy (wizyty pacjentów), dokumentacja medyczna jest przechowywana często na papierze co nie gwarantuje jej długiej żywotności. Beneficjenci projektu Właściciele gabinetów lekarskich. Właściciele prywatnych placówek stomatologicznych. Lekarze prowadzący prywatną praktykę. Efekty od zakończenia prac projektowych (wyniki, wpływy) Komplet oprogramowania do zarządzania działalnością gabinetu lekarskiego. Wdrożenie nowoczesnego sposobu prowadzenia placówki medycznej. Zadania do wykonania Popularyzacja systemu w placówkach gabinetów medycznych. Analiza wymagań użytkowników końcowych. Czas i zasięg zadań System musi zmierzyć się z realiami dzisiejszych czasów i wymaganiami stawianymi przed podobnymi rozwiązaniami w obecnych czasach. Zasięg zadań to przede wszystkim rynek lokalny, w późniejszym czasie ekspansja na inne rynki.
Sposoby ewaluacji zadań Rozmowy z końcowymi użytkownikami, ankiety funkcyjne, prezentacje wersji beta szerszemu gronu użytkowników. Kontynuacja projektu Dalszy rozwój oprogramowania. Konserwacja oprogramowania. Wdrażanie w innych placówkach medycznych.
Metoda punktów funkcyjnych Złożoność Opis Niska Średnia Duża Suma Wejście 2 3 3 4 1 6 24 Wyjście 4 4 2 5 2 7 40 Zapytania 0 3 0 4 0 6 0 Pliki wew. 1 7 1 10 1 15 32 Interfejs zew. 0 5 0 7 0 10 0 Ocena współczynników wpływu Wstępne oszacowanie 96 0-5 Przesyłanie danych 2 Obciążenie platformy 2 sprzętowej Stopa transakcji 1 Wydajność użytkownika 5 końcowego Przetwarzanie złożone 0 Łatwość instalacji 2 Wielokrotna lokalizacja 0 Wydajność 0 Przetwarzanie rozproszone 1 Wprowadzanie danych 5 on-line Aktualizacja on-line 1 Wielokrotna używalność 3 Łatwość obsługi 4 Łatwość wprowadzania 4 zmian Współczynniki wpływu 30 Współczynnik złożoności = 0,65+(0,01* 30 = 0,95 Punkty funkcyjne 0,95 * 96 = 91,2 Liczba linii kodu 3283,2 Liczba osób potrzebnych do wykonania projektu 3 Czas wykonania projektu 4
Lista kontrolna ryzyka Ryzyko związane z ustalaniem zadań TAK NIE Czy zadania są ustalane tylko ustnie? Czy opis zadań jest kompletny? Czy osoba ustalająca zadania posiada niezbędne kompetencje? Czy wymagane jest sprawdzenie wykonalności stawianych zadań? Czy wyjaśnianie zadań odbywa się pod presją czasu? Czy dokumentacja techniczna jest wystarczająca i kompletna? Czy zakres dokumentacji jest zdefiniowany? Czy wszystkie warunki odbioru i przekazywania zadań są jednoznacznie zdefiniowane? Ryzyko wynikające z technologii TAK NIE Czy stosowana technologia jest nowa lub jest stosowana po raz pierwszy? Czy stosowana technologia jest nowa dla klienta lub stosowana przez niego po raz pierwszy? Czy istnieją trudne warunki ze strony otoczenia? Czy w ramach wykonywanych usług mają być tworzone nowe produkty? Czy istnieją jakie, szczególne wymagania dotyczące technologii? Ryzyko wynikające z techniki TAK NIE Czy nowo opracowana technika ma być po raz pierwszy zastosowana (zastosowanie pilotażowe)? Czy technika jest stosowana po raz pierwszy w dziale? Czy technika jest bardzo złożona? Czy nowe techniki będą dominować podczas projektu, czy jedynie wspomagać prace? Czy istnieją normy jakości dla nowych technik?
Czy należy dopasować się do innych, funkcjonujących wcześniej elementów instalacji (obcych lub wykonanych przez nas)? Czy występują trudności związane z określoną przez klienta techniką? Czy konieczne jest przestrzeganie specjalnych wymaga) w zakresie np. jakości, norm, dyspozycyjności? Czy część projektu stanowi nietypowe rozwiązanie techniczne? Czy osiągnięto już granice wydajności? Czy proponowana technika jest już przestarzała? Ryzyko wynikające z techniki TAK NIE Czy termin końcowy jest absolutnie nieprzekraczalny? Czy wpływ opóźnienia terminu jest duży? Czy termin wymaga zastosowania nadzwyczajnych zdolności produkcyjnych? Czy czas trwania projektu jest nietypowo długi? Czy w dotrzymaniu terminu jesteśmy zależni od innych partnerów? Czy siatka terminów dla poszczególnych faz projektu jest nierealistyczna? Czy termin zdefiniowania zadań jest otwarty? Czy może dojść do wąskich gardeł czasowych (np. brak spełnienia warunków do rozpoczęcia budowy itd.)? Ryzyko zwiane z zespołem projektowym i personelem Czy powołano odpowiednią osobę na kierownika projektu? Czy brakuje ludzi z doświadczeniem? Czy powołano odpowiednią ilość osób i czy jest zapewniona ich dostępność w ustalonym czasie? Czy w czasie trwania projektu pracownicy mogą być okresowo niedostępni? Czy pracownicy powinni mieć szczególne kwalifikacje? Czy jest wymagana szczególna dyspozycyjność czasowa pracowników? TAK NIE
Czy klient stawia określone wymagania co do zatrudnianego personelu? Czy są potrzebni pracownicy z innych departamentów, wydziałów lub spoza firmy? Ryzyko związane z relacjami z klientem TAK NIE Czy mamy do czynienia z nowym klientem? Czy klient jest dla nas klientem strategicznym? Czy klient dysponuje kompetentnymi partnerami do kontaktów z naszej strony? Czy kompetencje decyzyjne u klienta są określone? Czy z udziału lub braku udziału klienta wynika jakieś ryzyko dla projektu? Czy relacje z klientem mają duży wpływ na przebieg prac projektowych? Czy niezbędne są dostawy urządzeń lub usługi ze strony klienta lub osób trzecich? Ryzyko związane z zakresem odpowiedzialności Czy zakres odpowiedzialności jest jasno zdefiniowany? Czy odpowiedzialność jest adekwatna do zakresu zlecenia? Czy przewidziana jest współodpowiedzialność za określanie zadań? Czy wyznaczone osoby akceptują przydzielony im zakres odpowiedzialności? Czy są obszary, dla których nie zostały powołane (z nazwiska) osoby odpowiedzialne? Czy określono odpowiedzialność za wszystkie działania serwisowe i pomocnicze? TAK NIE Ryzyko wynikające z warunków umowy TAK NIE Czy istnieją specjalne wymagania odnośnie wartości kontraktu? Czy forma rozliczeń może stanowić problem? Czy wszystkie punkty umowy są zaakceptowane? Czy szczególne warunki rozliczenia pociągają za sobą dodatkowe koszty? Czy okres gwarancji jest dłuższy niż 12 miesięcy? Jak zdefiniowano warunki odpowiedzialności cywilnej? Czy istnieją wymagania dotyczące odszkodowań, kar umownych?
Czy zostały udzielone dodatkowe poręczenia i gwarancje? Czy istnieją ustalenia dotyczące możliwości unieważnienia lub zerwania umowy? Jak określono terminy ofertowe i terminy obowiązywania cen? Ryzyko związane z transakcjami w obrocie międzynarodowym Czy istnieją jakieś ograniczenia eksportowe? Czy należności są fakturowane w obcych walutach? Czy korespondencja jest prowadzona w obcym języku? Czy konieczne jest przestrzeganie szczególnych norm, przepisów i regulaminów? Czy mają znaczenie zwyczaje i praktyki stosowane w innych krajach? Czy należy brać pod uwagę przepisy celne? Czy występuje ryzyko zwiększenia koszty transportu? TAK NIE Analiza ryzyka projektu Nazwa ryzyka Symptomy Skutki Prawdopodobi eństwo Działania korygujące Niedotrzymanie terminu złożenia pracy dyplomowej. Błędy na etapie projektowania. Zmiany wprowadzane w końcowym etapie Utrata danych. Nie przestrzeganie harmonogramu pracy. Funkcjonalności nie takie jakich oczekiwano. Zmiana wymagań stawianych przed systemem. Informacje ze S.M.A.R.T. Kara pieniężna i przesunięcie terminu obrony. Opóźnienia w dyplomowej. Opóźnienia w dyplomowej. Utrata kodu i dokumentacji już Brak. Przeanalizowanie wymagań stawianych oprogramowaniu Dokładne określenie wymagań na etapie proj. Kopie zapasowe robione
Słaba motywacja i brak chęci do pracy. Ciężka choroba. Niestabilne funkcjonowanie sprzętu. Spowolnienie prac nad projektem. Podupadanie na zdrowiu. wykonanej. Opóźnienia w dyplomowej. Opóźnienia w dyplomowej a nawet niemożliwość jej ukończenia. Wypadek. Brak. Opóźnienia w dyplomowej a nawet niemożliwość jej ukończenia. Problemy w korzystaniu z założonych technologii. Brak kontaktu z promotorem. Trudności w implementacji. Nie odpisywanie na maile, odwoływanie spotkań. Opóźnienia w dyplomowej. Brak możliwości podejścia do obrony. okresowo. Urlop, wykonywanie innych zadań w międzyczasie. Regularne wykonywanie badań. Brak. Zmiana wykorzystywany ch technologii. Zmiana promotora. Brak kontaktu ze strony odbiorcy aplikacji. Brak zainteresowania aplikacją ze strony odbiorcy lub brak czasu po jego stronie. Brak motywacji do ukończenia projektu. Inny odbiorca. Zdarzenie losowe. Brak. Opóźnienia w dyplomowej a nawet niemożliwość jej ukończenia. Brak. P. wysokie P. średnie P. niskie
Zarządzanie jakością Jakość Opis Sposoby poprawy Niezawodność Niezawodność to główny czynnik determinujący jakość oprogramowania. Systemy zawodne i niepracujące stabilnie są z góry skazane na porażkę. Czytelność Prostota i przejrzystość rozwiązań. Funkcjonalność Oprogramowanie powinno być funkcjonalne, aby użytkownik nie musiał wspomagać pracy innym oprogramowaniem. Użyteczność Użyteczność to cecha określająca prostotę używania oprogramowania i ilość czasu potrzebnego na zaadoptowania jego do swoich potrzeb. Testy Długotrwałe testy oprogramowania służą polepszaniu niezawodności. Trzymanie się prostych i sprawdzonych rozwiązań. Przemyślenie i sprecyzowanie wymagań funkcjonalnych grupy docelowej odbiorców. Użyteczność można poprawić np. projektując interfejs użytkownika zgodnie z zasadami usability. Cząstkowe Testowanie poprawności funkcji, klas, modułów oprogramowania. Systemowe Współgranie z innymi składnikami systemu np. bazami danych. Integracyjne Mają za zadanie przetestowanie spójności działania złożonego systemu zbudowanego z wielu modułów lub komponentów. Walidacja Działanie systemu musi prowadzić do zamierzonych wyników. W myśl zasady: od szczegółu do ogółu testy powinny być przeprowadzane na małych partiach oprogramowania. Wybieranie kompatybilnych między sobą wersji oprogramowania. Przygotowanie testów symulujących działalność użytkownika i analizowanie danych zebranych w ten sposób.
Błędy Systemowe Konflikty w systemie. Wejścia Konflikt między danymi wprowadzonymi przez użytkownika a tym czego oczekiwał system. Obróbka Błędy wynikające ze złego obliczania wartości w systemie np. zaokrąglanie liczby zmiennoprzecinkowej. Interfejs Błędy w interfejsie. Dokumentacja Błędy w dokumentacji. Sprawdzanie systemu pod kątem zgodności modułów działających w systemie. Stworzenie reguł uniemożliwiających wprowadzanie błędnych danych do systemu. Przygotowanie szerszego zbioru wartości do testowania. Walidacja Błędy otrzymanych wyników. Patrz błędy wejścia.