Projektowanie Aplikacji Komputerowych Projekty informatyczne 2014
Właściwości projektów informatycznych Unikalność Zakres Budżet Czas Zasoby Złożoność 2014
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 30-40 statystycznie średnio 15% projektów jest opóźnionych, a 25% jest zarzuconych przed ukończeniem”, Yourdon 2014
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 2014
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. 2014
Metodyka Metodyka zarządzania projektem jest narzędziem, która ma wspomagać proces realizacji projektu Przykładowe metodyki PRINCE2 PJM 2014
Cykl życia produktu a cykl życia projektu Idea Specyfikacja Analiza Projekt Implementacja Testowanie Wdrożenie Użytkowanie Wycofanie Projekt Produkt 2014
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 2014
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 2014
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ń 2014
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 2014
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 2014
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 2014
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 2014
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 1000-10000 10000-50000 >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 2014
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 2014
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 2014
Zarządzanie konfiguracją Identyfikacja elementów, które wymagają zarządzania konfiguracją Ocena ryzyka zmiany Rejestr zmian konfiguracji Autoryzacja zmian konfiguracji 2014
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 2014
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 2014
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 2014
Proces Właściciel+komitet sterujący Dostawca Procedura Odbiorca Kierownik+zespół 2014
Techniki PRINCE2 Planowanie nastawione na produkt Techniki kontroli zmian Przeglądy jakości Prowadzenie dokumentacji projektowej 2014
Planowanie nastawione na produkt Produkty projektu Produkty wspomagające zarządzanie Produkty wspomagające zapewnienie jakości 2014
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 2014
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 2014
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 2014
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) 2014
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 2000. Aplikacja przeznaczona do szybkiej i taniej realizacji badań ankietowych. Poza gromadzeniem danych zawiera moduł generowania dynamicznych raportów. 2014
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) 2014