Bardzo podoba mi się odpowiedź Williama Pietri (+1), ale uważam, że należy ją dodać. Nawet zakładając, że to, co rozumiesz przez systemy, składa się wyłącznie z oprogramowania.
Ale zanim przejdę do sedna sprawy, nie znam książki, która mogłaby pomóc. Wszystko, co następuje, nauczyłem się z doświadczenia (co oznacza trzy punkty, które podniósł William).
To, o czym mówisz, obejmuje co najmniej cztery szerokie role. Czasami jedna osoba może pełnić wszystkie te role, w przypadku małych i średnich projektów, ale kiedy zaczynasz od dużych projektów, musisz przynajmniej nieco je rozdzielić. Trudno jest być ekspertem od nich wszystkich w jakikolwiek znaczący sposób.
Analityk Biznesowy
To osoba, która rozmawia z klientem i przekłada jego wymagania na coś, co architekt może zrozumieć. Zasadniczo lista poprawnie sformułowanych wymagań. Obejmuje to oczywiste wymagania funkcjonalne (co musi zapewnić ten system?), Ale także wymagania niefunkcjonalne (jakie są ogólne cechy, które musi spełniać system? Może to obejmować bezpieczeństwo, niezawodność, dostępność, odporność, pojemność, wydajność, niezawodność i inne takie wymagania z punktu widzenia użytkownika).
To pierwsze przejście do tego, co musi zrobić system, początek poważnego myślenia.
Architekt systemu
Osoba ta tworzy ramy techniczne na wysokim poziomie, w których można pracować. Podają ogólny plan dopasowania. Ogólne narzędzia, techniki, konstrukcje. Rozkładają cały system na mniejsze elementy, jak pasują do siebie, jak pasują do świata zewnętrznego ...
Pomaga to na wiele sposobów dopracować to, o czym należy pomyśleć. Na tym etapie bardzo często pojawiają się problemy dotyczące wymagań napisanych przez analityka biznesowego. Wróć do nich, aby uzyskać kilka iteracji, aby lepiej zrozumieć, czego chcą i wyrazić to.
Projektant systemu
Ta rola polega na tym, jak sprawić, by wszystko działało. To może być więcej pracy zespołowej niż jednoosobowego serialu. Ale prawdopodobnie istnieje główny projektant, który nadzoruje cały projekt systemu. Ta osoba musi zagłębić się w szczegóły i upewnić się, że widok architekta jest czymś, co można zbudować.
Oczekuj dalszego udoskonalenia architektury systemu, a zatem potencjalnie analizy biznesowej.
Kierownik testów
Ta rola jest bardzo często zapominana. Ale na koniec dnia, jeśli nie możesz go przetestować, jak możesz udowodnić, że możesz go zbudować? Przegląd wszystkich etapów: analizy biznesowej, architektury i projektu musi zostać dokonany przez osobę kompetentną w testowaniu, która będzie w stanie wskazać braki i tym samym umożliwić wczesne korekty, na długo przed napisaniem kodu.
To krótkie podsumowanie.
Ci faceci / dziewczęta są tylko ogólną grupą ludzi w młynie, którzy myślą o tym, o czym należy pomyśleć.
W przypadku skomplikowanych projektów, takich jak duże aplikacje bankowe lub kosmiczne, aby wziąć dwa przykłady (pomyśl o setkach do wielu tysięcy osobodni), istnieje wielu ekspertów w tej dziedzinie, ponieważ nazywamy ich do przeglądu i wspierania projektów na każdym etapie. Role te obejmują analizę bezpieczeństwa, zmianę rozmiaru systemu, pojemność, wydajność, bazy danych, tworzenie klastrów i wiele innych tak wąskich dziedzin wiedzy specjalistycznej, w tym precyzyjne obszary biznesowe. Różnorodność ról zależy od wielkości i złożoności systemów.
Wszystko to, żeby powiedzieć, że nie powinieneś próbować tego wszystkiego wiedzieć, nie będziesz. Możesz jednak zapoznać się z ogólnym obrazem, a przy małych projektach możesz zagłębić się w znacznie więcej niż w duże projekty, po prostu dlatego, że poziom złożoności pozwala ci być bardziej zaokrąglony.
Jeśli chcesz wiedzieć, jak projektować systemy, musisz zacząć zadawać pytania, myśląc nieszablonowo. Postaw się wystarczająco w butach klienta i spróbuj pomyśleć, co może pójść nie tak, co wymaga testowania. Następnie spotkaj się z prawdziwym klientem i popchnij go, aby wyjaśnił zakres i ograniczenia systemu, którego potrzebują. Ponadto, gdy mówię „klient”, musisz zrozumieć, że obejmuje to kilka bardzo różnych osób. Jest osoba, która codziennie korzysta z systemu do tego, do czego został przeznaczony. Jest operator, wsparcie techniczne, menedżer, który potrzebuje jakiegoś raportu lub innego, audytor, zespół infrastruktury, interesariusz, który zapłacił za to, menedżer jakości, który potrzebuje środków do przetestowania twojego systemu ... Zapytaj wszystkich (a jeśli są jedną osobą, poproś ich, aby założyli wszystkie te czapki na raz), więc zapytaj ich wszystkich, czego potrzebują, a będziesz dobrze zacząć od poznania wymagań systemowych. Stamtąd można wyprowadzić architekturę, a stamtąd projekt.
W przypadku złożonych systemów (czy to tylko oprogramowania, czy też w celu integracji ze sprzętem w najbardziej ogólnym sensie) nie tylko jedna osoba nie wystarczy na każdą z czterech wyżej wymienionych ról, ale musisz zarządzać projektem nawet definicją tego, co system musi zrobić, nie mówiąc już o innych fazach.
HPH, asm.