Tworzenie listy zadań (działań) projektowych jest procesem dynamicznym, iteracyjnym i co najważniejsze twórczym. Oznacza to, że nic w tym procesie nie zastąpi wiedzy i doświadczenia kierownika projektu i jego zespołu, a najbezpieczniejszą drogą do sukcesu jest dekompozycja (uszczegółowienie) ogólnych zaleceń opisanych w Definicji zakresu systemu, z wykorzystaniem wcześniej opracowanych (wypraktykowanych) wzorców procesów produkcyjnych.

Dekompozycja na kategorie, grupy zadań, zadania elementarne itd. pozwala na łatwiejsze stworzenie szczegółowych opisów poszczególnych zadań, sprzyja bardziej wiarygodnemu określeniu i oszacowaniu zasobów potrzebnych do ich realizacji i ułatwia wykrycie wzajemnych powiązań między zadaniami, pozwalając na lepszą optymalizację wykorzystania zasobów.

Praktyczne wzorce (modele) cyklów "życia" oprogramowania, dostępne w licznych obecnie metodykach projektowania systemów informatycznych, ułatwiają planowanie odwołując się do sprawdzonych schematów postępowania, które wielokrotnie były już weryfikowane przez innych. Modele te spełniają ważną rolę w planowaniu, gdyż:

• dostarczają ogólnych ram organizacyjnych projektu

• wyznaczają główne fazy cyklu "życia" projektu

• wyznaczają zestawy podstawowych zadań i produktów dostarczanych przez ich realizację

• pomagają określić szczegółowe cele planowania, organizacji, szacowania zasobów, zarządzania projektem

• nakreślają ogólne zalecenia co do wymaganych narzędzi, metod

  są podstawą do oceny procesu produkcji oprogramowania i jego doskonalenia.

(Ważniejsze modele produkcji - cykli - oprogramowania są scharakteryzowane w tabeli 1.)

Liczba możliwych typów aplikacji, sposobów zorganizowania zespołów projektowych itp., wyklucza podanie gotowego przepisu na stworzenie "systemu informatycznego". Każdy nowy system jest inny i wymaga indywidualnego podejścia. Nawet korzystanie z gotowej metodyki projektowej nie zwalnia firmy od budowania swojej własnej, najlepiej odpowiadającej specyfice produkowanych przez nią aplikacji, metodyki - przepisu na dobry produkt.

Harmonogram

Kolejnym zadaniem kierownika projektu jest stworzenie - na podstawie listy zadań projektowych - harmonogramu projektu, który jest odniesiony do konkretnych uwarunkowań związanych z czasem, kosztem i środkami koniecznymi do realizacji zadań. Abstrakcyjne dotąd zadania, które zawierały jedynie opis koniecznych do wykonania czynności, charakterystykę produktów wejściowych i wyjściowych oraz różne informacje dodatkowe (patrz Kącik praktyka), konkretyzują się w określonym czasie i przestrzeni przez:

• określenie daty rozpoczęcia i zakończenia realizacji zadania

• określenie odpowiedzialnych za jego realizację

• określenie zasobów koniecznych do jego realizacji

• określenie warunków rozpoczęcia i zakończenia zadania

• określenie kosztu i pracochłonności zadania.

Proces tworzenia harmonogramu projektu obejmuje następujące czynności:

1 Szeregowanie zadań

Wszystkie zadania w projekcie są powiązane w łańcuchy zadań, które tworzą procedury, a te z kolei procesy, stanowiące główny składnik faz cyklu życia.

Między wszystkimi wymienionymi kategoriami działań istnieją różne interakcje i zależności merytoryczne i czasowe. Zadania poprzedniej fazy projektowej dostarczają produktów do fazy następnej, która nie może rozpocząć się bez zakończenia zadań związanych z weryfikacją tych produktów itd. O kolejności wykonania zadań decydują m.in.:

• charakterystyka produktu (systemu), np. projekt systemu zapewnienia jakości powinien być poprzedzony studiami odpowiednich norm

• natura procesów (tzw. sztywna logika procesu), np. testowanie może odbyć się dopiero wtedy, gdy system już istnieje i działa, a nie na etapie projektowania

• wymagania projektowe (tzw. miękka logika procesu), np. w pewnych przypadkach wydaje się uzasadnione przejście do fazy projektowania, mimo iż wymagania dla jednego z modułów nie zostały jeszcze do końca sformułowane

• wymagania zewnętrzne, np. ploter stosowany do testowania systemu raportów będzie dostępny dopiero za 2 miesiące.