Zrobiliśmy nasz pierwszy kurs online! Zapraszamy do kursu: Wykres Gantta w Excelu - https://www.subscribepage.io/gantwexcelu
W 2007 roku ukazała się książka Daniela J. Paulisha o zarządzaniu procesem tworzenia oprogramowania. Autor radzi, aby zarządzanie oparte było na architekturze tworzonego produktu. Dlaczego takie rozwiązanie proponuje autor? Odpowiedź na to pytanie, poparte doświadczeniami zawodowymi autora, znajdziemy w jego książce.
Paulish w swojej książce pod pojęciem architektury oprogramowania ma na myśli uchwycenie struktur systemu i powiązań między nimi. Dzieli je na ogólne kategorie: pojęciową, modułową, wykonawczą i kodową. Podkreśla, że przy realizowaniu projektu informatycznego należy już w początkowej fazie stworzyć architekturę oprogramowania.
Architekt odpowiedzialny jest za architekturę oprogramowania, za jej zaprojektowanie, modyfikowanie oraz upublicznianie.
Kierownik projektu wspólnie z architektem kierują przedsięwzięciem. Mają oczywiście różne obowiązki i kompetencje.
Kierownik projektu określa sposób osiągnięcia wizji, którą odzwierciedla architektura.
Najważniejsze właściwości zarządzania
W zaproponowanym przez Paulisha sposobie zarządzania, wyróżnione zostały następujące właściwości:
- Projektowanie i opis architektury — do osiągnięcia sukcesu konieczne jest stworzenie zrozumiałej dla wszystkich architektury rozwiązania, która znana jest już na początku implementacji.
- Planowanie przedsięwzięcia — planowanie projektu powinno odbywać się jednocześnie z tworzeniem architektury, a harmonogramy powinny być na niej oparte.
- Tworzenie przyrostowe — oprogramowanie powinno być tworzone przyrostowo, najpierw stworzony zostaje „wycinek pionowy”, który jest następnie poszerzany o kolejne funkcje.
- Zespół kierownik przedsięwzięcia — architekt — występują dwie role (najczęściej dwie osoby): kierownika — osoby odpowiadającej za zarządzanie i architekta — osoby odpowiedzialnej za technologię.
- Analiza kompromisów — kierownicy muszą być odpowiednio elastyczni, podejmując decyzje, muszą również zgadzać się na kompromisy.
- Czynniki „miękkie” — bardzo ważny element tworzenia oprogramowania. Są to m.in.: budowanie zespołu, morale, zależność od kierownictwa, sytuacji rynkowej, doświadczenia personelu i kultura.
Role w zespole
W zespole tworzącym oprogramowanie wyróżnione zostały role:
- Kierownik projektu — odpowiada za zarządzanie całym przedsięwzięciem.
- Architekt — tworzy architekturę rozwiązania i opiekuje się nią.
- Kierownik zespołu — zarządza własnym zespołem wytwórczym oraz przydzielonymi modułami do wytworzenia.
- Twórca oprogramowania — projektuje, implementuje oraz testuje komponenty systemu.
- Majster budowlany — scala moduły systemu oraz testuje zintegrowane moduły. Odpowiada za zarządzanie konfiguracją.
- Kierownik komórki testowania systemowego — odpowiada za testy odbiorcze, spójność dokumentacji z produktem.Kierownik komórki marketingu lub kierownik produktu — definiuje funkcjonalność produktu, specyfikuje wymagania funkcjonalne i niefunkcjonalne, pomaga ustalać priorytety wykrytych błędów.
Planowanie
Równolegle z tworzeniem architektury rozwiązania, kierownik tworzy plany najpierw „od ogółu do szczegółu”. Po rozpoznaniu głównych obszarów i modułów produktu są one przydzielane członkom zespołu, którzy stają się za nie odpowiedzialni. Oni szacują ich pracochłonność metodą „od szczegółu to ogółu”. Mając wyniki powyższych prac, należy stworzyć harmonogram wersji (przy tworzeniu przyrostowym) oraz całego produktu. Konieczne jest przy tym uwzględnić osobiste harmonogramy członków zespołu.
Analiza globalna
Analiza globalna to analizowanie czynników zależnych od firmy, czynników technicznych i związanych z produktem, które wywierają globalny wpływ na projekt architektury. W jej skład wchodzi analiza powyższych czynników, wyciąganie wniosków dotyczących przedsięwzięcia, analiza ryzyka, ocena architektury, tworzenie strategii dla projektu, planowanie testów.