Przeglądaj katalog alfabetyczny według autorów, tytułów lub słów kluczowych. Kliknij odpowiedni przycisk poniżej, a następnie wybierz pierwszą literę nazwiska, tytułu czy słowa kluczowego.
Wyszukiwarka pełnotekstowa (kliknij)
Frączkowski K., Zarządzanie projektem informatycznym,
Wydawnictwo Politechniki Wrocławskiej, Wrocław 2003, ISBN: 83-7085-731-0
Projekt (ang. Project) jest nowym przedsięwzięciem, nie mającym wzorca, nie realizowanym wcześniej. Dotyczy nowej sytuacji, wymaga nierutynowego podejścia. Nie możemy polegać na historycznych sposobach postępowania z danym problemem. Projekt jest to przedsięwzięcie, na które składa się zespół czynności, które są charakterystyczne przez to, że mają datę rozpoczęcia, specyficzne cele i limity, ustalone odpowiedzialności (obowiązki) realizatorów, budżet, rozkład czynności oraz datę ich ukończenia(gdy celem projektu jest rozwinięcie systemu oprogramowania, wtedy jest to projekt rozwoju oprogramowania lub projekt inżynierii oprogramowania). Podane cechy decydują o tym, że jest to nowe przedsięwzięcie nie mające wzorca, nie będące rutynowymi działaniami, nie realizowane wcześniej. Projekt, projektowanie - twórcza działalność związana z powstawaniem produktu, powodująca jego zróżnicowanie wynikające z cech, parametrów użytkowych, zgodności ze standardami, trwałości, niezawodności, łatwości naprawy i dającego się odróżnić od innych projektów stylu. Projekt ma wizje, najczęściej zawiera rysunki, schematy, obliczenia, opisy, kosztorysy itp. dotyczące wykonania danego urządzenia, przedmiotu, systemu informatycznego lub obiektu budowlanego.
( , s. 11-12)
Zarządzanie Definicji zarządzania jest wiele, tak jak książek na ten temat. Większość z nich dąży do zwięzłego i precyzyjnego zdefiniowania istoty zagadnienia, jednak to czym jest zarządzanie zależy od szczebla, obszaru i organizacji, gdzie następuje proces zarządzania. Jedna z definicji mówi, że zarządzanie to dokładne poznanie tego, czego się oczekuje od ludzi, a następnie dopilnowanie, aby wykonali to w najlepszy i najtańszy sposób Taylor. Shop Manager, Harper & Row, New York 1903, s. 21.
( , s. 11)
Projekt "od dołu do góry" (ang. Buttom-up design) - proces projektowania systemu przez identyfikację składowych niższego poziomu, projektowanie struktury w celu zintegrowania składowych niższego poziomu w coraz większe podsystemy, aż projekt będzie ukończony.
( , s. 12)
Projekt "od góry do dołu" (ang. Top down design) - proces projektowania systemu poprzez identyfikację jego większych składników, rozłożenie ich na składniki niższego poziomu oraz rozdzielanie dopóki pożądany poziom szczegółowości nie zostanie osiągnięty, jest to działanie przeciwne do projektu "od dołu do góry".
( , s. 12)
Projekt inżynierii oprogramowania (ang. Software engineering project) - zestaw wszystkich czynności, funkcji i zadań zarówno technicznych, jak i menedżerskich, wymaganych do zaspokojenia terminów i warunków realizacji projektu. Projekt inżynierii oprogramowania może być częścią większego projektu. Projekt inżynierii oprogramowania jest czynnością charakteryzującą się datą startu, specyficznymi celami i limitami, ustanowionymi obowiązkami, budżetem i planem oraz datą ukończenia.Projekt inżynierii oprogramowania zużywa zasoby, które spełniają wymagania projektu, wyszczególnione w uzgodnieniach projektowych. W niektórych przypadkach projekt może obejmować tylko porcję produktu oprogramowania, może trwać wiele lat i składać się z licznych podprojektów.
( , s. 12)
Projekt inżynierii systemu (ang. System engineering project) - zestaw wszystkich czynności, funkcji zarówno technicznych, jak i zarządczych, wymaganych do zaspokojenia terminów i warunków realizacji projektu. Projekt inżynierii systemu jest czynnością charakteryzującą się datą startu, specyficznymi celami i limitami, ustanowionymi obowiązkami, budżetem i planem oraz datą ukończenia. Zużywa zasoby i ma na celu wytworzenie produktu lub zestawu produktów, które zaspokajają wymagania projektu wyszczególnione w specyfikacji projektu. W niektórych przypadkach może obejmować tylko porcję produktu oprogramowania, trwać wiele lat i składać się z licznych podprojektów.
( , s. 12-13)
Projektowanie-do-kosztu (ang. Desing-to-cost) - podejście w zarządzania projektem, polegające na utrzymania projektu w granicach kosztu przewidzianego w harmonogramie. To znaczy, że przebieg projektowania jest oceniany (oszacowywany) poprzez monitorowanie jednostkowych wymagań w kolejności zależnej od ważności oraz ustanowienie rygorystycznych celów kosztowych do projektowania i wykonania każdego zadania. Aby to osiągnąć, rezerwuje się zapas na przypadki odstępstwa kosztów (zwykle 15-20%), szukając praktycznego kompromisu między operacyjnymi możliwościami wykonawczymi, zakresem i harmonogramem.
( , s. 13)
Projekt wstępny (ang. Preliminary desing) - 1. Proces analizowania alternatyw projektu oraz definiowania architektury sprzętu/systemu oprogramowania. W inżynierii oprogramowania wstępny projekt zwykle zawiera definicję oraz strukturę komputerowych składników programów i danych, definicje interfejsów oraz przygotowanie rozmieszczenia w czasie i oszacowania kosztów. 2. Wynik przebiegu procesów projektowania wstępnego. Niekiedy rozumiany jako opis projektu stępnego.
( , s. 13)
Projektowanie szczegółowe (ang. Detalied design) - 1. W inżynierii oprogramowania proces weryfikacji polegający na usuwaniu błędów, rozszerzaniu projektu wstępnego oprogramowania w celu zawarcia bardziej szczegółowych opisów logiki przetwarzania, struktur danych oraz definicji danych do tego stopnia, gdzie projekt jest wystarczająco szczegółowy, aby mógł zostać wdrożony. 2.Wynik szczegółowego procesu projektowania. Niekiedy bliskoznaczny z opisem specyfikacji projektu szczegółowego.
( , s. 13)
Projekt systemu (ang. System design) - 1. Proces definiowania architektury, jej składników, modułów funkcjonalnych, interfejsu, danych, sprzętu/oprogramowania dla systemu w celu zaspokojenia wyszczególnionego wymagania systemu. 2. Wynik przebiegu procesów projektowania systemu. Bliskoznaczny projektowi architektury.
( , s. 13)
Projekt oprogramowania (ang. Software desing) - proces definiowania architektury oprogramowania składników, modułów, interfejsów, podejścia testowego oraz danych dla systemu oprogramowania.
( , s. 13)
Proces jest to ściśle zdefiniowany ciąg działań nastawionych na ustabilizowanie i optymalizację stanowiących podstawę technologii wytwarzania wielu identycznych lub podobnych produktów o określonych parametrach użytkowych lub świadczonych usługach. Przez technologię należy rozumieć przetwarzanie w sposób celowy i ekonomiczny z zastosowaniem nowej techniki 48.
( , s. 15)
Komentarze i źródła pierwotne: Lapkiewicz J., Frączkowski K., High-Availability Infrastructure Architecture, Web Hosting Transi-tion. Materiały VII Konferencji i Warsztatów użytkowników ORACLE. Ploug 2001. Zakopane Kościelisko 23-27.108.2001
Tarnowski B.T., Project Management - elastyczność czy kaftan bezpieczeństwa?, II Konferencja Project Management - perspektywy i doświadczenia, Stowarzyszenie Project Management Polska (SPMP), Gdańsk, 2000.
Ograniczeniami w projekcie są czynniki, które mają podstawowy wpływ na opcje działań kierownika projektu. Typowe trzy główne ograniczenia to: - Harmonogram - ograniczenia, takie jak stała data zakończenia lub termin ostateczny w przypadku głównych punktów kontrolnych. - Zasoby - (materiał, wyposażenie, sprzęt i ludzie oraz skojarzone z nimi koszty) - ograniczenie, takie jak uprzednio zdefiniowany budżet. - Zakres - ograniczenie, takie jak zakładana funkcjonalność, technologia, produkty itp.
( , s. 21)
Pula zasobów umożliwia współużytkowanie zasobów przez wiele projektów. Używanie puli zasobów umożliwia sporządzanie harmonogramów dla zasobów pracy we wszystkich projektach, identyfikację konfliktów między przydziałami w różnych projektach i monitorowanie, wykorzystywania czasu zasobu w wielu projektach. Jeżeli informacje o ludziach lub sprzęcie pracującym nad zadaniami znajdują się w wielu plikach projektów, można użyć puli zasobów do centralizacji informacji o zasobach, takich jak nazwa zasobu, używany kalendarz, jednostki zasobu i tabele stawek kosztów, co ułatwi zarządzanie projektem. Każdy projekt, który używa zasobów z puli zasobów, jest nazywany plikiem współużytkującym. Jako puli zasobów można używać dowolnego, istniejącego pliku projektu, ale zaleca się utworzenie nowego pliku projektu tylko na informacje o zasobach, by jak najbardziej ułatwić zarządzanie informacjami o zasobach i przydziałami zadań między plikami współużytkującymi a pulą zasobów.
( , s. 21)
Studium wykonalności projektu (SWP) - stwierdza, czy dany projekt przy danych zasobach ma szanse wykonania (zakończenia się sukcesem).
( , s. 22)
Inicjowanie projektu (IP) - zbiór czynności, które należy podjąć przed formalnym uruchomieniem cyklu prac nad projektem: - opis rozwiązania technicznego, - opis (wstępny plan) projektu (ang. Business Case), - ustanowienie projektu.
( , s. 22)
Wybór strategii rozwoju projektu jest poprzedzony analizą wielkości projektu, horyzontu czasowego jego realizacji, poziomem dopuszczalnego ryzyka i innymi czynnikami. Wyróżnia się kilka strategii, które mają swoje nazwy: - fazowa, monolityczna - sekwencja kolejno wykonywanych faz, dobra dla projektów o niskim poziomie ryzyka, - wydania, wersje - wytwarzane są fragmenty (podsystemy, komponenty), inkrementalne podsystemy mogą powstawać w sekwencji lub równolegle, ich oddzielne wytwarzanie zmniejsza ryzyko ich uruchomienia - szybkiej ścieżki, prototypowania - wytwarzany jest prototyp, następnie wykonywana jest jego ocena, po której wytwarzany jest system, zalecana przy wysokim ryzyku, - mieszana - fragmenty (podprojekty) powstają według różnych strategii, szczególnie przydatna dla dużych projektów obarczonych dużym ryzykiem
( , s. 24-25)
Struktura WBS reprezentuje pracę nad wytworzeniem indywidualnych komponentów i pracę nad integracją komponentów w projekt. Głównym celem struktury WBS jest przejrzysta i adekwatna do rodzaju projektu organizacja powiązań i współdziałania wytwarzanych produktów zmierzających do osiągnięcia celu projektu. Umożliwia graficzne wyobrażenie i sprawdzenie czy dany projekt ma szanse realizacji. Wszystko to, co znajduje się w projekcie musi się znajdować w strukturze WBS. Jeśli czegoś nie ma uwzględnionego w WBS, to oznacza, że nie ma tego w projekcie. WBS może być strukturą hierarchiczną drzewa. Począwszy od korzenia do liści, wzrasta stopień szczegółowości opisu WBS. Komponentami WBS mogą być zarówno produkty, jak i usługi 26, 32. Plan projektu powinien być dokładny, zawierać wszystkie zadania, czynności niezbędne do osiągnięcia zamierzonych celów projektu. Struktura WBS powinna to umożliwiać.
( , s. 26-27)
Komentarze i źródła pierwotne: Badiru A.B., Project Management in Manufacturing and High Technology Operations, Willey, New York, 1988.
IFPUG, International Function Point Users Group, Function Point Counting Practices Manual, Release 3.0, IFPUG, Werterrille, Ohio, 1990.
Liberatore M.J., A Decision Support System Linking Research And Development Project Selection with Business Strategy, Project Management Journal, November 1988.
Metoda punktów funkcyjnych (PF) jest stosowana przede wszystkim do szacowania pracochłonności i jakości oprogramowania.
( , s. 33)
Punkty funkcyjne (PF) są rozumiane jako miara wielkości aplikacji komputerowych i projektu, które należy stworzyć. Jest to miara stworzona głównie na użytek szacowania wielkości i kosztów projektu, które np. negocjujemy we wstępnej fazie projektu z klientem.
( , s. 34)