Projektowanie Aplikacji Komputerowych

Slides:



Advertisements
Podobne prezentacje
Kamil Markuszewski Mateusz Mikłuszka
Advertisements

Project management w procesie budowy grona
KOMUNIKACJA W ZESPOLE PROJEKTOWYM
Ćwiczenia praktyczne – zadanie nr 16
Analiza ryzyka projektu
JAKOŚĆ & Metody Jej Pomiaru
Zarządzanie projektem (ZPR)
Zarządzanie przedsięwzięciami i PRINCE2
Zarządzanie projektami – pojęcia
JAKOŚĆ PRODUKTU - USŁUGI
Propozycja metodyki nauczania inżynierii oprogramowania
ZASADY AUDITOWANIA ZARZĄDZANIE PROGRAMEM AUDITÓW
ISO 9001:2000 z perspektywy CMMI a poznańska rzeczywistość
Zarządzanie przedsięwzięciami i PRINCE2
Tomasz Pieciukiewicz Rafał Hryniów
Zasady metodyki Prince 2
Jakość systemów informacyjnych (aspekt eksploatacyjny)
RYZYKO OPERACYJNE Jak przeciwdziałać mu w praktyce?
Rational Unified Process
Współpraca tłumacza z BT przed zdobyciem i po zdobyciu certyfikatu normy PN:EN Autor: Magdalena Gałczyńska Firma: BTInfo Biuro Tłumaczeń Informatycznych.
Praca Inżynierska „Analiza i projekt aplikacji informatycznej do wspomagania wybranych zadań ośrodków sportowych” Dyplomant: Marcin Iwanicki Promotor:
Bardzo ważnym elementem metodologii projektowania systemów informatycznych jest PMBoK PMBoK (ang. Project Management Body of Knowledge) jest zbiorem standardów.
Specjalista do spraw odnawialnych źródeł energii
Wykład 2 Cykl życia systemu informacyjnego
Projekt z Baz Danych II Łukasz Wiatrak Marta Kowalczyk Krzysztof Cywicki.
Wykonawcy:Magdalena Bęczkowska Łukasz Maliszewski Piotr Kwiatek Piotr Litwiniuk Paweł Głębocki.
ŚCIEŻKA KRYTYCZNA Ciąg następujących po sobie zadań w ramach projektu trwających najdłużej ze wszystkich możliwych ciągów, mających taką własność, że opóźnienie.
Projekt z Baz Danych II Łukasz Wiatrak Marta Kowalczyk Krzysztof Cywicki.
Wewnętrzny system zapewniania jakości PJWSTK - główne założenia i kierunki działań w ramach projektu „Kaizen - japońska jakość w PJWSTK” Projekt współfinansowany.
Microsoft Solution Framework
Zarządzanie jakością projektu
Rozwiązania informatyczne dla przedsiębiorstw
Metodyki zarządzania projektami
Klucze do sukcesów w zarządzaniu
Metodyki zarządzania projektami
Elektroniczne Biuro Obsługi Interesanta Tamara Ossowska Zakopane, 21 czerwca 2001.
Zarządzanie projektami
Spotkanie Centrum Poczty i Postdata S.A.
Program Operacyjny Kapitał Ludzki
Zmiany w wymaganiach normy ISO (w kontekście EMAS)
KONTROLA ZARZĄDCZA - 1 Kontrolę zarządczą stanowi ogół
Ewaluacja konferencja 11 czerwca 2014 RODN „WOM” w Katowicach.
SYSTEM FUNKCJI, PROCESÓW I PRZEDSIĘWZIĘĆ W ORGANIZACJI.
Wstęp do zarządzania projektami
Agenda O Nas Ogólne informacje o Produkcie Job Manager – idealne rozwiązanie Aplikacja Webowa Aplikacja Kliencka Najnowsze zmiany.
Zarządzanie projektami informatycznymi
Projektowanie Aplikacji Komputerowych
Podstawy zarządzania projektami Karta projektu
Copyright © Jerzy R. Nawrocki Team Software Process Inżynieria oprogramowania II Wykład.
ZINTEGROWANE SYSTEMY ZARZĄDZANIA
Eksploatacja zasobów informatycznych przedsiębiorstwa.
Eksploatacja zasobów informatycznych przedsiębiorstwa.
Ergonomia procesów informacyjnych
SYSTEM ZARZĄDZANIA BEZPIECZEŃSTWEM INFORMACJI- wymagania normy ISO 27001:2007 Grażyna Szydłowska.
Sposoby doboru metod i narzędzi do komunikacji w zespole projektowym
Karolina Muszyńska. Spis zagadnień Wprowadzenie Znaczenie zarządzania komunikacją dla powodzenia projektu Praktyki zarządzania komunikacją w zespołach.
Logical Framework Approach Metoda Macierzy Logicznej
Moduł e-Kontroli Grzegorz Dziurla.
Organizacja zespołu projektowego
Innowacyjne metody zarządzania jakością oprogramowania, Zarządzanie ryzykiem w metodyce PRINCE2 Jerzy Nawrocki
Zarządzanie ryzykiem w projektach Poznań, r.
Faza 1: Faza zaprojektowania systemu monitoringu projektu: 1. Inwentaryzacja obietnic złożonych sponsorowi we wniosku - przegląd założeń projektu, opracowanie.
Przygotowanie projektów unijnych
„Metodologia Zarządzania Cyklem Projektu (PCM) — klucz do sukcesu
Zarządzanie projektami informatycznymi
Metodyka PRINCE 2 w zarządzaniu projektami informatycznymi administracji publicznej – inicjowanie projektu dr inż. Stefan Rozmus PRINCE2 Registered Practitioner.
IV Konferencja Naukowo-Techniczna "Nowoczesne technologie w projektowaniu, budowie.
[Nazwa projektu] Analiza zamknięcia
IEEE SPMP Autor : Tomasz Czwarno
Zgłoszenie w ramach kategorii Razem
Zapis prezentacji:

Projektowanie Aplikacji Komputerowych Projekty informatyczne 2008

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

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 2008

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

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

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

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

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

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

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

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

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

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

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

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 2008

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

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

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

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

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

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

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

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

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

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

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

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

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

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. 2008

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