Recenzja książki: Zarządzanie architekturocentrycznym procesem tworzenia oprogramowania — przewodnik praktyczny

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.

Organizacja, realizacja i mierzenie przedsięwzięcia

W dalszych rozdziałach znajdziemy informacje o organizacji przedsiębiorstwa, sposobach tworzenia oprogramowania przez rozproszone, wielokulturowe zespoły, budowaniu kultury pracy i zespołów. Znajdują się tam rady jak podejmować decyzje i kiedy warto iść na kompromis, jak zarządzać przyrostowym tworzeniem oprogramowania, jak zachować zimną krew, gdy gonią terminy.

Końcowe rozdziały poruszają tematykę mierzenia projektu oraz samego tworzonego produktu. Znajdziemy tam m.in.: czym jest dobrze wykonany produkt oraz dobrze zrealizowany projekt.

Analiza przypadków

Ostatnie dwa rozdziały zawierają zawodowe doświadczenia autora z tworzenia Imaging System 2000 — system zobrazowania danych pochodzących z sond oraz Data Processing System 2000 — oprogramowanie do pozyskiwania i przetwarzania danych z liczników energii elektrycznej, gazu i wody. Są to przykłady, gdzie autor zastosował proponowane w omawianej książce metody zarządzania.

Podsumowanie

Książka zawiera bardzo dużo użytecznej wiedzy. Jest trochę innym spojrzeniem na tworzenie oprogramowania. W czasach, gdy często wykorzystuje się zbyt dosłownie zasadę: nie rób czegoś, co nie jest Ci teraz potrzebne (YAGNI — ang. You Aren’t Gonna Need It) zapomina się o zrobieniu pełnego projektu architektury oprogramowania, trzymania się jej oraz, w razie potrzeby, aktualizowania jej. Tworząc architekturę oprogramowania już na początku projektu, możesz wydzielić w niej niezależne moduły oraz zdefiniować ich interfejsy. Dobrze zaprojektowane i wyprodukowane komponenty mają ogromny potencjał do wykorzystania w innych projektach! Jeśli masz wiele zespołów, które mogą być w rozrzucone po całym świecie, możesz przydzielić im niezależne moduły. Dzięki temu szybciej zrealizujesz projekt. Jasny i klarowny model architektury to nie tylko umożliwienie efektywniejszej pracy zespołów i ułatwienie komunikacji, ale również ogromne ułatwienie dla nowych pracowników.

Zobacz podobne wpisy:

• Recenzja książki: Sprawne zarządzanie projektami metodą ScrumKarol Bocian
• Recenzja książki: Zarządzanie architekturocentrycznym procesem tworzenia oprogramowania — przewodnik praktycznyKarol Bocian
• Recenzja książki: Myśl jak programistaKarol Bocian
• Zarabiaj więcej i awansuj szybciej – 21 sposobów na przyspieszenie kariery. Brian TracyKarol Bocian
• Filozofia Kaizen w biurze — William Lareau — PomiaryKarol Bocian
• Lean. Droga do minimalizmu – Tomasz KrólIwona Rojek
• W tym szaleństwie jest metoda – Marcin ŻmigrodzkiIwona Rojek
• Recenzja książki: Zrobione! Naucz się kończyć to, co zacząłeś – Jon AcuffKarol Bocian
• Wieczne opóźnienie – Marcin Dąbrowski – Recenzja książkiKarol Bocian
• Zwinni Zbrodnia i Scrum – Marcin ŻmigrodzkiKarol Bocian

• 1
• 2
• >>

Źródła:

• Inżynieria oprogramowania. Zarządzanie architekturocentrycznym procesem tworzenia oprogramowania. Przewodnik praktyczny, Paulish Daniel J., 2007, WNT.

Zdjęcia:

• https://www.pexels.com/photo/man-wearing-white-hard-hat-leaning-on-table-with-sketch-plans-1260309/