Norma IEEE 1058.1-1987 SPMP Warszawa, 2004-05-09 IEEE - The Institute for Electrical and Electronics Engineering - Instytut inynierii elektrycznej i elektronicznej SPMP - Software Project Management Plan - Plan zarzdzania projektami oprogramowania 1) IEEE - Instytut inynierii elektrycznej i elektronicznej IEEE Wizja Globalny postp koniunktury poprzez rozwijanie innowacji technologicznych, umoliwianie kształtowania karier członków oraz promowanie rodowiska na całym wiecie. IEEE Misja IEEE promuje inynierskie procesy tworzenia, rozwijania, integrowanie, współdzielenia oraz dostarczania wiedzy o elektrycznych i informatycznych technologiach i naukach dla korzyci ludzkoci i profesji/zawodu. IEEE Organizacja : http://www.ieee.org Techniczne Profesjonalne Zrzeszenie nie czerpice korzyci z działalnoci Około 380 000 członków, w 150 krajach Około 300 znaczcych konferencji rocznie Około 900 czynnych standardów, w tym 700 rozwijanych IEEE Standardy : Rozwijane w rodowiskach technicznych Dobrowolne bez kompensacji Uywanie standardów jest dobrowolne Standardy s tematami przegldów co 5 lat Szeroko rozpowszechnione i uywane w USA IEEE Standard 1058.1-1987 : Standard dla Planu Zarzdzania Projektem (SPMP) Definiuje format oraz zawarto Planu Zarzdzania Projektem (SPMP) NIE specyfikuje uywanych technik lub przykładów Stosowany moe by do kadego rodzaju projektów Stosowany moe by do projektów dowolnej wielkoci Copyright 2004 Tomasz Czwarno All Rights Reserved 1
2) SPMP - Plan zarzdzania projektami oprogramowania - Szablon Strona tytułowa Lista zmian Przedmowa Spis treci Lista osób Lista tabel Lista figur 1. Wprowadzenie (Introduction) 1.1 Zarys projektu (Project overview) 1.2 Produkty projektu (Project deliverables) 1.3 Ewolucja planu projektu (Evolution of the project management plan) 1.4 Dokumenty powizane (Reference materials) 1.5 Definicje i akronimy (Definitions and acronyms) 2. Organizacja projektu (Project organization) 2.1 Model procesu projektowego (Process model) 2.2 Struktura organizacyjna (Organizational structure) 2.3 Granice organizacyjne i interfejsy (Organizational boundaries and interfaces) 2.4 Podział odpowiedzialnoci (Project responsibilities) 3. Zarzdzanie (Managerial process) 3.1 Cele i priorytety zarzdzania (Management objectives and priorities) 3.2 Załoenia, uwarunkowania i ograniczenia (Assumptions, dependencies, and constraints) 3.3 Zarzdzanie ryzykiem (Risk management) 3.4 Mechanizmy ledzenia i kontroli (Monitoring and controlling mechanisms) 3.5 Plan zatrudnienia (Staffing plan) 4. Proces techniczny (Technical process) 4.1 Metody, narzdzia i techniki (Methods, tools, and techniques) 4.2 Dokumentacja oprogramowania (Software documentation) 4.3 Funkcje wspomagajce projekt (Project support functions) 5. Etapy pracy, harmonogram i budet (Work packages, schedule, and budget) 5.1 Podział projektu na etapy i zadania (Work packages) 5.2 Zalenoci (Dependencies) 5.3 Wymagania zasobów (Resource requirements) 5.4 Budet i rozdział zasobów (Budget and resource allocation) 5.5 Harmonogram (Schedule) Dodatkowe komponenty Indeks Załczniki Copyright 2004 Tomasz Czwarno All Rights Reserved 2
3) SMPE - Plan zarzdzania projektami oprogramowania - Opis 1. Wprowadzenie 1.1 Zarys projektu Cele projektu, opis projektu, znaczce działania, kroki milowe, wymagane zasoby, główny budet, główny harmonogram, wymagany personel. 1.2 Produkty projektu Lista wszystkich elementów projektu bdcych przedmiotem dostawy, wraz z dat dostarczenia, ilociami i miejscem. 1.3 Ewolucja planu projektu Uaktualniania procesu tworzenie SPMP. SPMP zgodnie z planem zarzdzania konfiguracj (Configuration Management). Wszystkie zmiany musz by udokumentowane tak aby SPMP był prawidłowy i aktualny. Np.: Kto zatwierdza zmiany przed ich implementacj?, Jak czsto i kto bdzie uaktualniał ten dokument? 1.4 Dokumenty powizane Lista wszystkich dokumentów powizanych z planem oraz mechanizmy wyszukiwania wraz z aktualnymi wersjami. Np.: Opis projektu, Analiza obiektowa, Specyfikacja, Odniesienia do standardów pisania kodu, dokumentacji i testów. 1.5 Definicje i akronimy Lista wszystkich akronimów i skrótów uywanych w dokumencie wraz z rozwiniciami. Np.: JAR = Java ARchive 2. Organizacja projektu 2.1 Model procesu projektowego Opis procesów rozwoju projektu (software development process). Model moe by przedstawiony w formie wykresu z zamieszczonymi opisami i datami) Np.: Proces rozwoju bdzie oparty na modelu spiralnym z szybkim prototypowaniem. Iteracjom bd podlegały procesy analizy, projektowania, implementacji i testowania. Copyright 2004 Tomasz Czwarno All Rights Reserved 3
2.2 Struktura organizacyjna Wewntrzna struktura zarzdzanie projektem (Internal management structures), ksigowo projektu, raportowanie, odpowiedzialnoci itd. Okrelenie ról (team manager, configuration manager, quality assurance leader, requirements management leader, design leader, implementation leader, database manager, webmaster) Np.: Zespół bdzie podzielony na pod grupy, pracujce niezalenie/ pełnice poszczególne role. 2.3 Granice organizacyjne i interfejsy Specyfikacja interfejsu pomidzy projektem a organizacjami, powizanymi z projektem, takimi jak : organizacja sponsora, organizacja rodzima, organizacja klienta, organizacja podwykonawcy itd. Np.: Kto bdzie spotykał si z klientem i kto bdzie dokumentował modyfikacje. 2.4 Podział odpowiedzialnoci Lista wszystkich funkcji i/lub aktywnoci (znaczcych, dostarczanych klientowi) wraz z odpowiedzialnociami (jednostkowymi lub imiennymi). 3. Zarzdzanie 3.1 Cele i priorytety zarzdzania Opis celów i priorytetów w zarzdzaniu projektem. Np.: Produkt bdzie najlepszym wyprodukowanym produktem przez organizacj, Priorytetami bd : zadowolenie klienta, dostawa na czas, edukacja pracowników. 3.2 Załoenia, uwarunkowania i ograniczenia Załoenie projektowe. Uwarunkowania organizacyjne, zdarzeniowe (wewntrzne i zewntrzne) oraz wspierane funkcje zalene od projektu. Ograniczenia mog zalee od wymaga organizacyjnych, budetowych, harmonogramowych itd. Np. Załoenia : system operacyjny, Uwarunkowania : JDK1.3, Ograniczenia : Swing 3.3 Zarzdzanie ryzykiem Czynniki ryzyka, ocena ryzyka, ledzenie ryzyka, łagodzenie wystpienia ryzyka. Plan zarzdzania ryzykiem (Risk management plan) lub odniesienie do niego. 3.4 Mechanizmy ledzenia i kontroli Definicje weryfikacji i procedur poprawnoci (audyty, przegldy, inspekcje, przejcia przez ryzyko), list dystrybucyjnych, mechanizmów raportowania i formaty. Copyright 2004 Tomasz Czwarno All Rights Reserved 4
3.5 Plan zatrudnienia Opis wszystkich umiejtnoci wymaganych w kadej fazie projektowej, wraz z czasem rozpoczcia i okresem trwania. Np.: Jakie osoby bd potrzebne w projekcie, w której fazie i na jak długo. 4. Proces techniczny 4.1 Metody, narzdzia i techniki Opis lub odniesienie do technicznych metod rozwoju oprogramowania. Odniesienia do: Planu zarzdzania konfiguracj (configuration management plan), Planu zapewnienia jakoci (quality plan), Planu zaopatrzenia (procurement plan). Np.: Opis systemu rozwojowego (UNIX, PII), kocowego (WINDOWS, PIV), testowego (WINDOWS, PIII). Metody programowania (obiektowe), dokumentowania (javadocs) 4.2 Dokumentacja oprogramowania Opis lub odniesienie do planu dokumentacji, zawierajce konwencj nazwow oraz style. Opis dokumentów powstałych po kadym kroku milowym. Np.: Dokumentacja bdzie wykonywana za pomoc JavDoc u lub standardów przyjtych w danej organizacji. 4.3 Funkcje wspomagajce projekt Lista wymaganych i wspieranych przez projekt funkcji. Zapewnienie jakoci (quality assurance), Wsparcie sekretariatu (secretarial support), Wsparcie negacyjne (contract negotiation support). Wsparcie zarzdzania, kto bdzie odpowiedzialny itd. W szczególnoci, naley tu okreli zadania, wymagania zasobów, harmonogram i budet dla kadej funkcji wspomagajcej. 5. Etapy pracy, harmonogram i budet 5.1 Podział projektu na etapy i zadania Lista etapów i zada wykonywanych w projekcie wraz z identyfikatorami. Np.: Diagramu WBS 5.2 Zalenoci Opis kolejnoci wykonywania poszczególnych etapów i zada. Dla przedstawienia zalenoci pomidzy etapami pracy i działaniami mona zastosowa listy zalenoci (ang.dependency lists), sieci działa (ang. activity networks) lub metody cieek krytycznych (ang. critical path method). Copyright 2004 Tomasz Czwarno All Rights Reserved 5
Np.: Diagramu PERT 5.3 Wymagania zasobów Lista wymaganych zasobów, obejmujca ludzi, sprzt, oprogramowanie, pomieszczenia itd. 5.4 Budet i rozdział zasobów Budet z podziałem na etapy i zadania wykonywane w projekcie. Rozdział zasobów z podziałem na fazy projektu oraz etapy i zadania wykonywane w projekcie. 5.5 Harmonogram Harmonogram z podziałem na etapy i zadania wykonywane w projekcie. Harmonogram powinien uwzgldnia czas trwania kadej z aktywnoci lub dat ukoczenia. Np.: Diagram GANTT Copyright 2004 Tomasz Czwarno All Rights Reserved 6