| Dyscyplina analizowania i projektowania systemów informatycznych w środowisku procesu wytwórczego |
|---|
| Napisane przez Mon 17 Nov 2008 przez Artur (4838 cztane) |
|
Wieloletnie doświadczenie przy produkcji oprogramowania pozwala zauważyć, że właściwe wykorzystanie takich dyscyplin w produkcji oprogramowania jak: modelowanie biznesowe oraz analiza i projektowanie często jest nie możliwe i najczęściej zagrożone przez środowisko w jakim projekt się znajduje. Istnieje wiele czynników destruktywnych dla zastosowania wymienionych dyscyplin. Artykuł ma na celu zobrazować problematykę praktycznego wykorzystania takich niezbędnych dyscyplin inżynierii oprogramowania w projektach systemów informatycznych, jak: modelowanie biznesowe, analiza i projektowanie. Wymieniając te istotne czynniki, które często zauważają analitycy i projektanci, pozwolę sobie wykorzystać popularne a zarazem wymowne rysunki, opisujące niezrozumienie zleceniodawców projektu oraz często uczestników projektu. W każdej z części niniejszego artykułu przedstawię skuteczną propozycję zniwelowania tych problemów. Chętnie napisałbym, że najważniejszą kwestią w produkcji oprogramowania są oczekiwania klienta od systemu. Jednak obawiam się, że użyte sformułowanie „oczekiwania klienta od systemu” będzie różnorako interpretowane. Wobec tego, uwydatnię ten etap projektu, bo de facto jest najważniejszy. W tej części artykułu skupię uwagę na „aktorze biznesowym” i „aktorze systemowym”. Zastanawia mnie bowiem powszechne zrozumienie problematyki rozróżnienia aktora biznesowego od aktora systemowego przy produkcji oprogramowania. Chciałbym zaznaczyć tu również rolę i znaczenie klienta a w gruncie rzeczy: rozróżnić kilka postaci w projekcie, które w różnych projektach i środowiskach zamiennie nazywa się „klientem”. Diagram 1 Diagram 1 przedstawia klasy: klient, aktor biznesowy, aktor systemowy. Przedstawiony związek zależności pomiędzy aktorami oraz agregacja aktorów przez klienta została stworzona w oparciu o kontekst, w jakim producent oprogramowania powinien postrzegać te główne role na etapie określania wymagań dla systemu informatycznego. Faktem oczywistym jest, że klient jest najczęściej zleceniodawcą i inicjatorem produkcji oprogramowania. Jednak dla członków zespołu projektowego nie ten fakt jest istotny. Bowiem, dla nich szczególnie ważną informacją jest, czy klient rozróżnia pojęcia przedstawione na diagramie 1 i jeżeli tak, to czy poprawnie definiuje ich znaczenie. Ustalenie definicji pojęć: aktor biznesowy, aktor systemowy, klient - jest najistotniejsze w problemie przedstawionym na rysunku 1 („To, co klient zamówił”). Definiując pojęcie klienta, uznajmy wobec tego, że to ta rola w projekcie - która definiuje m.in. znaczenie klas przedstawionych na diagramie 1 - aktora biznesowego, aktora systemowego. Aktor biznesowy, prawdopodobnie jest najbardziej narażoną rolą na błędną jego interpretację. Często stwierdza się, że aktor biznesowy nie jest inicjatorem procesu biznesowego. Różna interpretacja i definicja procesu biznesowego, przyczynia się pośrednio do niejednoznacznych stwierdzeń o znaczeniu pojęcia „aktor biznesowy”. W tym artykule uznaję jednoznacznie definicję RUP (Rational Unified Process). Aktor biznesowy to niewątpliwie taki obiekt na modelu biznesowym, który znajduje się poza granicami systemu informacyjnego (poza organizacją, której procesy biznesowe modelujemy) i przyczynia się do istnienia procesów biznesowych tej organizacji. Aktor systemowy to przyszły użytkownik produkowanego systemu. Jednak zważywszy na realia w jakich dedykowane oprogramowanie powstaje, aktor systemowy nie zawsze określa wymagania dla systemu, którego ostatecznie używa - w celu zaspokojenia oczekiwań wynikających ze specyfikacji procesów biznesowych. Aktor systemowy jest najczęściej najbardziej poszkodowaną rolą na etapie określania wymagań. Dlatego, że najczęściej to nie on ustanawia kształt procesu biznesowego i jest zależny od wielu, często niespójnych źródeł informacji. Rozwiązanie problemu dotyczącego błędnej definicji oczekiwań przez samego klienta oraz niezrozumieniu wymagań klienta przez zespół projektowy wiąże się zasadniczo z jednolitą definicją pojęć: aktor biznesowy, aktor systemowy oraz klient przez uczestników projektu. Kolejny rysunek pt. „To, co analityk zrozumiał” sygnalizuje o błędnym zrozumieniu wymagań klienta przez analityka. Faktem jest, że otoczenie, w którym analityk wykonuje pracę jest często nieuporządkowane. Efekty pracy analityka są najbardziej z wszystkich ról w projekcie narażone na wpływ współczynników destruktywnych dla powodzenia projektu. Jedną z istotniejszych kwestii w zrozumieniu problematyki „To, co analityk zrozumiał” jest zdefiniowanie stanowiska pracy, roli w projekcie oraz wymagań stawianym analitykom. Wiadomo powszechnie, że analityk jest tą rolą w projekcie, która występuje pomiędzy klientem a zespołem projektowym systemu informatycznego. Analityk jest tą osoba, która rozwiązuje lub często wpływa na rozwiązanie szerokiego spektrum problemów, poczynając od developerskich a kończąc na handlowych. Prowadzi przy tym szkolenia oraz negocjuje wszystko i z wszystkimi. Można byłoby tym samym stwierdzić, że analityk jest niemalże kręgosłupem projektu systemu informatycznego. Niewątpliwie na efektywność pracy analityka mają wpływ różne czynniki. Poniższy Diagram 2, przedstawia otoczenie i jego wpływ na pracę analityka. Diagram 2 Diagram przedstawia następujące klasy: • Specyfika klienta • Komunikacja z klientem • Specyfika zespołu projektowego • Komunikacja zespołu projektowego • Problemy natury inżynierii oprogramowania • Problemy natury techniki oprogramowania • Problemy natury handlowej • Komunikatywność i efektywność negocjacyjna Jak wynika z diagramu 2, na środowisko pracy analityka składają się, co najmniej: specyfika klienta, komunikacja z klientem, specyfika zespołu projektowego, komunikacja zespołu projektowego, problemy natury inżynierii oprogramowania, problemy natury techniki oprogramowania, problemy natury handlowej, komunikatywność i efektywność negocjacyjna analityka. Zakres i sposób oddziaływania otoczenia na efekty pracy analityka, jest najczęściej zależny od niego samego. Trudno sobie wyobrazić, aby praca analityka w wieloosobowych i złożonych projektach bez ścisłego związku z zarządem projektu była efektywna. Wytypowanie w projekcie analityka wiąże się również z akceptacją stawianych przez analityka wymagań wobec zarządu i kierownictwa projektu w zakresie: • Koordynacji komunikacji z klientem • Zarządzania komunikacją w zespole projektowym • Współtworzeniu ofert handlowych • Wykorzystaniu zasad i doświadczeń inżynierii oprogramowania Podsumowując, spójność prac analitycznych z organizacyjnymi projektu jest podstawą do zniwelowania problemu błędnego zrozumienia wymagań klienta przez analityka. Wymaga to jednak ścisłej współpracy analityka nie tylko z klientem ale również i zarządem projektu. Przedstawione wcześniej zagadnienia problematyczne w takich obszarach projektu, jak: „To, co zamówił klient” oraz „To, co analityk zrozumiał” w efekcie, często przyczyniają się błędnego opisu projektu. Nie rozróżnienie aktorów biznesowych od systemowych, rozwiązywanie problemów „Ad hoc”, nie kontrolowanie informacji zamieszczanych w repozytorium projektowym, bagatelizowanie podstaw inżynierii oprogramowania, pozostawienie procesu wytwórczego w dystansie do prac projektowych - skutkuje chaosem. Kluczowe dla opisu projektu jest: kompetentność uczestników projektu nie tylko w zakresie docelowych efektów ich pracy (np. programowanie, zarządzanie projektem) ale również posługiwanie się wspólnym dla projektu językiem UML w zgodzie, co najważniejsze, z zasadami ustalonego procesu wytwórczego. Otóż, to właśnie zgodność prac z określonym procesem wytwórczym jest drogą do sukcesu. Zunifikowany język modelowania UML, bez określonych zasad praktycznego użycia, jest mało efektywny i trudny w praktycznym zastosowaniu. Poniższy diagram, przedstawia zależność opisu projektu systemu informatycznego od: kompetencji autorów, stosowanego procesu wytwórczego, ilości czasu poświęconego na pracę, klienta. Rysunek 3 Szczególną uwagę należy poświęcić na interpretację zależności pomiędzy przedstawionymi na diagramie klasami. Otóż, co istotne, opis projektu jest zależny od tych wszystkich elementów jego otoczenia. Oznacza to, że nie uwzględnienie oddziaływanie otoczenia - uniemożliwia poprawny opis projektu. Przy czym, o efektywności opisu projektu decyduje bezpośrednio taka jego zawartość, która wynika z bieżących potrzeb zaangażowanych uczestników projektu. |
| Indeks :: Drukuj :: E-mail |
Komentarze są własnością ich autorów. Nie ponosimy odpowiedzialności za ich treść.
| Postujący | Wątek |
|---|
| Postujący | Wątek |
|---|
| Postujący | Wątek |
|---|
| Postujący | Wątek |
|---|
| Postujący | Wątek |
|---|
| Postujący | Wątek |
|---|
| Postujący | Wątek |
|---|
| Postujący | Wątek |
|---|
