Wiedząc, czym są drivery biznesowe i drivery architektoniczne oraz jak działają wzorce projektowania, można przejść do projektowania rozwiązania.
W tym artykule zastanowimy się, czym naprawdę jest projektowanie i jak się ono do ruchu Agile. Odpowiem również na pytanie: jak projektować, by nie tworzyć niepotrzebnej pracy?
Czym jest projektowanie oprogramowania?
Projektowanie oprogramowanie polega na przekształceniu wymagań użytkownika w formę, która pomaga zespołowi w programowaniu i wdrażaniu oprogramowania. Podczas projektowania muszą zostać uwzględnione takie czynniki, jak: wymagania użytkownika, warunki techniczne, dostępne narzędzia, drivery biznesowe i architektoniczne. Te elementy stanowią punkt wyjścia dla procesu projektowania i pozwalają na wypracowanie odpowiedniego rozwiązania.
Do najważniejszych form, które przybiera programowanie, zaliczam:
- diagram architektoniczny systemu, który pozwala na określenie struktury systemu oraz relacji pomiędzy jego elementami;
- listę komponentów lub warstw, które składają się na system. Pozwalają na określenie funkcjonalności oraz zakresu systemu;
- procesy biznesowe w systemie oraz przypadki użycia, które pomagają w zrozumieniu potrzeb użytkowników oraz pozwalają na wyznaczenie odpowiednich funkcjonalności;
- wykorzystywane systemy zewnętrzne, umożliwiające ich integrację z rozwiązaniami tworzonymi przez zespół;
- wybrane technologie i języki programowania mające znaczący wpływ na cały proces projektowania, wpływające na możliwości tworzenia rozwiązań oraz ich efektywność.
Projektowanie jest kluczowym elementem w procesie SDLC, ponieważ zapewnia solidne fundamenty dla dalszej pracy zespołu oraz przyspiesza proces wdrażania oprogramowania.
Podczas projektowania rozwiązania musimy uwzględnić informacje zebrane w poprzednich fazach. Bez wiedzy na temat driverów biznesowych i architektonicznych istnieje wysokie ryzyko stworzenia błędnie zaprojektowanego rozwiązania, niespełniającego oczekiwań użytkowników.
Dlatego ważne jest, aby projektowanie poprzedzone zostało solidną analizą wymagań.
Cele projektowania
Projektowanie rozwiązania ma na celu uspójnienie zrozumienia wymagań oraz przekształcenie ich w konkretne rozwiązanie. W trakcie tego procesu, projektanci oprogramowania (developerzy, liderzy, architekci) dążą do umożliwienia zadawania bardziej złożonych pytań, które pomagają w znajdowaniu potencjalnych dziur w wymaganiach i rozwiązaniu.
Projektowanie rozwiązania jest kluczowym elementem ma etapie zrozumienia propozycji rozwiązania przez cały zespół i organizację. Dzięki projektowaniu można również oszacować zakres prac i zdefiniować ryzyka związane z danym projektem, co umożliwia unikanie niepotrzebnych opóźnień i kosztów.
Jak projektować, żeby to miało sens?
Przede wszystkim: zawsze projektujemy, żeby osiągnąć określony cel. Rzadko kiedy projektujemy dla samego projektowania. 😊
Dlatego projektujmy na podstawie potrzeb użytkowników i biznesu, a nie na naszych preferencjach czy pomysłach. Ważne jest również, by w czasie projektowania rozwiązania kierować się wartością, jaką dany projekt ma przynieść i nie tworzyć kolejnych artefaktów.
Pomogą Ci w tym odpowiedzi na dwie kwestie, które omawiam poniżej.
Dostosowanie techniki do problemu
Nie ma sensu stosować jednej techniki projektowania do każdego rodzaju problemu, ponieważ każdy problem jest inny i wymaga indywidualnego podejścia.
Podczas projektowania rozwiązania ustal, na jakie pytania ma odpowiadać projekt rozwiązania:
- Jakie funkcje mamy spełnić?
- Jakie są przypadki użycia?
- Jak mają wyglądać procesy biznesowe?
- Jakie są części składowe systemu?
- Jak wygląda komunikacja w systemie?
O tym, jak dobrać właściwą technikę projektowania i kiedy się to sprawdza, opowiem w kolejnych artykułach.
Dopasowanie techniki do odbiorców
Podczas projektowania rozwiązań nie wystarczy dostosować technikę do problemu. Równie ważna jest znajomość grupy odbiorców i programowanie z myślą o ich potrzebach. Bez tego projekt nie spełni swojej funkcji, a nawet najlepsze techniki okażą się nieskuteczne , gdy odbiorcy nie będą mogli lub chcieli korzystać z zaprojektowanych dla nich artefaktów.
Warto zadać sobie takie pytania:
- Do kogo jest skierowany ten projekt?
- Jakie grupy odbiorców są w nim zaangażowane?
- Czy istnieją materiały skierowane do różnych grup?
- Czy chcemy do nich inaczej dotrzeć?
- Jak mogę nauczyć odbiorców technik?
Czy projektowanie jest zwinne?
Odpowiedź na to pytanie brzmi: nie wiem. Bo jak dla mnie samo pytanie jest bez sensu.
Simon Brown, twórca modelu C4, podkreśla, że ważne jest określenie głównego ryzyka projektowego i usystematyzowania go wg priorytetów szansy wystąpienia i mocy rażenia. W ten sposób można projektować rozwiązanie tak, aby odpowiadało na najważniejsze ryzyka i je zmniejszało. Dzięki takiemu podejściu można stosować bardziej złożone metody, gdy sytuacja tego wymaga, ale także skupić się na programowaniu, gdy problem jest prostszy.
Kluczem projektowania jest umiejętność dostosowania technik do problemu, a także znajomość odbiorców rozwiązania, którzy powinni mieć wpływ na proces projektowania. Dyskusja, czy projektowanie jest zwinne czy nie, jest drugorzędna.
Polecam
Na koniec tradycyjnie polecam dwie książki w temacie projektowania:
- Just Enough Software Architecture: A Risk-Driven Approach George H. Fairbanks - z niej mocno czerpał Simon Brown.
- Fundamentals of Software Architecture: An Engineering Approach Neal Ford i Mark Richards - która również dużo mówi o projektowaniu.
