Projektowanie Aplikacji Komputerowych

Prezentacja na temat: "Projektowanie Aplikacji Komputerowych"— Zapis prezentacji:

1 Projektowanie Aplikacji Komputerowych
Projekty informatyczne 2008

2 Właściwości projektów informatycznych
Unikalność Zakres Budżet Czas Zasoby Złożoność 2008

3 Fakty Im większy projekt, tym większe prawdopodobieństwo opóźnienia
„Na podstawie zbadanych dziesiątków tysięcy projektów informatycznych w ciągu ostatnich statystycznie średnio 15% projektów jest opóźnionych, a 25% jest zarzuconych przed ukończeniem”, Yourdon 2008

4 Fakty „Statystycznie 30% projektów jest zarzuconych a tylko 16% projektów informatycznych jest ukończonych w założonym czasie i budżecie.”, Kashif Manzoor „Nasze studia pokazują, że tylko 5% systemów jest zbudowanych w założonym czasie i budżecie. Inne studia pokazują, że tylko 1% komercyjnych projektów informatycznych jest ukończonych w przewidywanym czasie, budżecie i zakresie. Co więcej, 75% projektów rozpoczętych są nigdy nie ukończone lub nie są zadowalające”, Stan Zawrotny 2008

5 Przyczyny niepowodzeń projektów informatycznych
Brak wiedzy biznesowej Rozszerzanie zakresu projektu Nieuwzględnienie ograniczeń Niepełna lista zadań Nieuwzględnienie zależności zadań Błędnie oszacowane koszty siły roboczej Błędnie oszacowane koszty stałe Brak kompetencji Nieuwzględnienie danych historycznych WHY DO IS PROJECT ESTIMATES FAIL? By definition, a manager must manipulate time and resources. The challenge facing managers today is to control costs, while gaining the maximum productivity from their resources, and in the shortest possible time. The means to accomplish this end are clear: the project manager must carefully plan and schedule the project, and monitor its progress so that corrective action can be taken when appropriate. By using more reliable estimates, the related tasks of planning and scheduling can be much more effective and less corrective action will be needed. The concept is simple but the application is often quite difficult. Producing a realistic project estimate is a formidable task because so many factors must be considered: KNOWLEDGE OF THE BUSINESS APPLICATION - It's evident that developers must understand the user's business to solve the problem; but planners must also understand the situation to effectively estimate the magnitude and complexity of the effort. PROJECT SCOPE - IS projects are infamous for their changing requirements. These are usually the result of constantly changing business and technological environments, but also include "scope creep" where the users want a never-ending series of "minor changes." CONSTRAINTS - Unrealistic staff, budget, hardware, quality, legal, and schedule constraints are a fact of life, and project managers must learn to factor them into their estimates and make the sponsors aware of their impacts. Unfortunately, there is a natural tendency to underestimate the time and resources needed. Realizing that management may refuse authorization for a project if realistic estimates are given, the inclination is to minimize the difficulties as a means of getting approval for the project. Project managers figure they can make up the time with overtime. But scheduled overtime leaves no buffer for contingencies. COMPREHENSIVE TASK LISTS - In Managing Software Projects (QED, 1990), Lois Zells declares that the problem with software estimates "often stems from the fact that the bulk of the effort required to complete the job is simply overlooked during the estimating process. In other words, it's what is left out of the estimate that usually gets the estimators in trouble." According to a Center for Project Management survey, typical IS projects are underplanned by a factor of 67%. Gopal Kapur maintains that the lack of a well-defined lifecycle methodology is a key factor in the undersizing and underplanning of projects. TASK DEPENDENCIES - Incorrect dependencies among tasks often result in expensive resources sitting idle waiting for a predecessor task to end. LABOR COSTS - Labor costs should include internal staff salaries as well as contractor personnel. If possible, "fully-loaded" salaries should be used, reflecting the costs of employee benefits as well as pure salaries. FIXED COSTS - These usually include software licenses, hardware, travel, and supplies. Overhead such as administrative services should also be included. RESOURCE SKILLS - Baseline estimates are usually based on the effort required for an expert to complete the tasks. Realistically, experts are not available for every task and an "average" resource might take as much as two-and-a-half times longer than an expert. The project manager must somehow balance the cost of the resources with the effect that the resources' skill-levels have on the project duration. HISTORICAL DATA - Companies that are able to develop accurate estimates are usually those who maintain a data base of historical data. If such a data base is not available, a company can begin by using one of the industry data bases offered by several vendors of cost estimating packages. Your own company's experience should then be used to validate and update the generic history. At a minimum, the organization should record their plans' actual costs and durations and refer to that information when estimating a new project. 2008

6 Metodyka Metodyka zarządzania projektem jest narzędziem, która ma wspomagać proces realizacji projektu Przykładowe metodyki PRINCE2 PJM 2008

7 Cykl życia produktu a cykl życia projektu
Idea Specyfikacja Analiza Projekt Implementacja Testowanie Wdrożenie Użytkowanie Wycofanie Projekt Produkt 2008

8 Elementy składowe metodyki PRINCE2
Organizacja Planowanie Fazy Zarządzanie jakością Zarządzanie ryzykiem Metody i narzędzia kontroli projektu Zarządzanie konfiguracją Kontrola zmian 2008

9 Organizacja Projekt jest realizowany w środowisku klient-dostawca
Zespół projektowy Komitet sterujący Sponsor i egzekutor Główny użytkownik Główny egzekutor Kierownik projektu Kierownicy zespołów i zespoły projektowe Kontrola jakości Wsparcie projektowe 2008

10 Zakres odpowiedzialności
Komitet sterujący Kontrola, definiowanie i zatwierdzanie funduszy Ma być na bieżąco informowany o wszelkich odchyłkach od planu Decyzje są jednogłośne Główny użytkownik Zna cele biznesowe Wie jakie będą zyski z wdrożenia projektu Zapewni dostępność zasobów Zapewni zgodność z założeniami Usuwanie przeszkód Raportowanie do kierownictwa Zwoływanie posiedzeń 2008

11 Zakres odpowiedzialności cd
Główny wykonawca Ocena kosztów Zapewnienie zasobów Zatwierdzanie zmian Zapewni zgodność z założeniami Kierownik projektu Całościowa odpowiedzialność Zapewnienie infrastruktury Planowanie Monitorowanie kosztów, czasu, problemów Zarządzanie Raportowanie 2008

12 Plan Elementy planu Poziomy
Produkty projektu Działania potrzebne do ich dostarczenia Zależności między działaniami Poziomy Projektu Faz Pracy zespołów Plan awaryjny - opracowanie alternatywnego planu 2008

13 Fazy Fazy projektu pozwalają na lepszą kontrolę realizacji projektu
Rozpoczęcie każdej fazy jest punktem decyzyjnym Dla każdej fazy należy określić produkty, które mają być w niej dostarczone 2008

14 Zarządzanie ryzykiem Ryzyka biznesowe Ryzyka projektowe
Nieosiągalne cele biznesowe Zmiany prawne Czynniki polityczne Niestabilność Ryzyka projektowe Brak zasobów Brak kompetencji Wadliwe narzędzi i technologie Niedostateczne testowanie Ryzyko zależności od dostawców zewnętrznych 2008

15 Analiza i reakcja na ryzyko, mapa ryzyka
Identyfikacja Oszacowanie prawdopodobieństwa i skutków Ocena (w kontekście podejmowanych akcji) Reakcja Zapobieganie Redukcja Transfer Utworzenie rezerw Akceptacja Mapa ryzyka Mapa ryzyka – definicja poziomów prawdopodobieństw i skutków może być zupełnie inna Skutek Prawdopodobieństwo <1000 >50000 <1% 1,2 7 1-10% 3,4 10-50% 6 5 >50% Ryzka 1,2,3,4,6,7 są akceptowalne Na ryzyko nr. 5 musi być reakcja 2008

16 Narzędzia kontroli projektu
Dokumentacja: Inicjujące projekt Oceny końca faz Raporty postępu prac Wczesne ostrzeżenia Cząstkowa ocena etapu Zamknięcia projektu 2008

17 Cele dokumentacji Inicjującej projekt Kontrolującej postęp
Cel projektu Uzasadnieni biznesowe Zakres uprawnień Granice projektu Założenia Ryzyka projektu Terminy dostaw Fazy Koszty Wstępny plan Kontrolującej postęp Opis dostaw Zlecenia zadań Kontrola zmian Rejestr ryzyka Planowanie Raport końca faz Kontrola jakości Kończącej projekt Powiadomienie o zakończeniu Zdobyte doświadczenia Rekomendowane akcje Raport końcowy Uwagi użytkowników 2008

18 Zarządzanie konfiguracją
Identyfikacja elementów, które wymagają zarządzania konfiguracją Ocena ryzyka zmiany Rejestr zmian konfiguracji Autoryzacja zmian konfiguracji 2008

19 Zarządzanie jakością Jakość – spełnienie oczekiwań klienta
Jakość oznacza, że produkt charakteryzuje się pewnymi parametrami, które są przewidywalne Przykłady norm jakości ISO JURAN CROSBY Należy zidentyfikować oczekiwania klienta co do jakości produktu Kontroli jakości podlegają procesy: Planowania Zarządzanie wytwarzaniem produktów Zarządzanie zakresem etapu Zapewnienie jakości Audyty Księga jakości 2008

20 Kontrola zmian Każda zmiana musi być zaakceptowana przez obie strony
Zmiana musi zostać zarejestrowana Należy sprawdzić wpływ zmiany na realizację projektu koszty czas zasoby 2008

21 Procesy metodyki PRINCE2
Rozpoczęcie projektu Przygotowanie założeń i celów. Powołanie zespołów. Planowanie prac przygotowawczych. Przygotowanie projektu Definicja założeń biznesowych, ryzyk. Powołanie zasobów. Podział prac na fazy i zdefiniowanie dostaw, produktów. Zarządzanie projektem Komitet sterujący podejmuje decyzje dotyczące rozpoczęcia, zakończenie faz oraz przydziela zasoby. Kierowanie fazą Monitorowanie postępów, ryzyk, kierowanie pracami wykonawczymi. Zarządzanie wytwarzaniem produktów Zapewnienie jakości odebranych dostaw, produktów. Rozpoczynanie nowej fazy Identyfikacja planowanych i osiągniętych wyników fazy zakończonej. Zamykanie projektu Dokumentacja prac, zdobyte doświadczenia („lesson learned”), ostateczny odbiór. Planowanie 2008

22 Proces Właściciel+komitet sterujący Dostawca Procedura Odbiorca
Kierownik+zespół 2008

23 Techniki PRINCE2 Planowanie nastawione na produkt
Techniki kontroli zmian Przeglądy jakości Prowadzenie dokumentacji projektowej 2008

24 Planowanie nastawione na produkt
Produkty projektu Produkty wspomagające zarządzanie Produkty wspomagające zapewnienie jakości 2008

25 Techniki kontroli zmian
Każda zmiana musi być odpowiednio udokumentowana: kto co kiedy dlaczego Analiza wpływu zmiany na projekt czas zakres zasoby budżet 2008

26 Przeglądy jakości Przeglądy jakości muszą być zaplanowane Etapy
Przygotowanie przeglądu Przeprowadzenie przeglądu Wnioski i rekomendacje Uczestnicy przeglądu jakości (role) prowadzący przegląd jakości dostawca odbiorca protokolant 2008

27 Prowadzenie dokumentacji
Dokumenty projektowe dokument inicjujący projekt analizy specyfikacje plany testów formularze zmian zlecenia zadań protokoły ze spotkań Inne dokumenty poczta elektroniczna 2008

28 Narzędzia kierownika Komunikacyjne Obiegu dokumentów
Telefon Poczta elektroniczna Telekonferencje Videokonferencje Obiegu dokumentów Repozytorium dokumentów Archiwizacja Publikowania dokumentów Narzędzia do publikacji na stronach WWW Planowania Microsoft Project (plan, zasoby, pracochłonność, koszty, postęp) 2008

29 Zrealizowane projekty informatyczne w WSZiM
Komputerowy System Weryfikacji Wiedzy aplikacja napisana w VB 6.0, współpracująca z SQL 2000, przeznaczona do sprawdzania stopnia opanowania wiedzy z różnych przedmiotów. Funkcjonuje w lokalnej sieci komputerowej. Testy internetowe aplikacja napisana w technologii ASP z wykorzystaniem dokumentów XML jako źródła danych. Przeznaczona do weryfikacji stopnia opanowania wiedzy z różnych przedmiotów. Pozwala także na ocenę swojej odpowiedzi Testy intranetowe aplikacja napisana w technologii ASP z wykorzystaniem dokumentów XML jako źródła danych. Przeznaczona do weryfikacji stopnia opanowania wiedzy z różnych przedmiotów. Pozwala także na ocenę swojej odpowiedzi. Wyniki testu gromadzone są w SQL 2000 Ankieta UE aplikacja napisana w technologii ASP, współpracująca z SQL Aplikacja przeznaczona do szybkiej i taniej realizacji badań ankietowych. Poza gromadzeniem danych zawiera moduł generowania dynamicznych raportów. 2008

30 Cechy projektów w WSZiM i metody realizacji
Duże zespoły (30-40 osób) Ograniczenia czasowe (16 godzin lekcyjnych) Duże rozproszenie geograficzne zasobów Metody Metodyka prowadzenia projektów Intensywna komunikacja (>100 maili) Praca zdalna (internet) 2008