| Praktyczne wykorzystanie zaleceń RUP (Rational Unified Process) na stanowisku Analityka Biznesowego. |
|---|
| Napisane przez Mon 19 Mar 2012 przez Artur (1093 cztane) |
|
Praktyczne wykorzystanie zaleceń RUP (Rational Unified Process) na stanowisku Analityka Biznesowego. Umiejętność praktycznego wykorzystania na stanowisku Analityka metod i narzędzi Inżynierii Oprogramowania, wydaje się bardzo wartościowa. Bowiem efekty z tej pracy przesądzają najczęściej o rezultacie końcowym całego przedsięwzięcia. Co wynika zasadniczo z definiowania na tym etapie, zarówno celowości jak i sposobu prowadzenia prac przez cały zespół wytwórczy. Na uwagę zasługuje tu fakt, że doświadczenia pojedynczej osoby w stosunku do zbioru wiedzy Inżynieria Oprogramowania - wypadają zwykle słabo. A więc, myśląc o jakości pracy, nie pozostaje Nam nic innego jak budować wiedzę w oparciu o Inżynierię Oprogramowania i doświadczenia innych w zastosowaniu tej wiedzy. Artykuł porusza praktyczne wykorzystanie wybranych zagadnień metodyki RUP (Rational Unified Process) na stanowisku analityka biznesowego w przedsięwzięciu IT. Definiuje wnioski z praktycznego użycia pewnych technik oraz zasadnicze wyzwania zespołu i potencjalne problemy. W podsumowaniu artykułu znajdują się również odnośniki do szkoleń i specjalistycznych usług inżynierskich związanych z tematem artykułu. DOWIESZ SIĘ - Jakie są doświadczenia z kilkuletniego zastosowania paradygmatu obiektowości na stanowisku Analityka Biznesowego w komercyjnych przedsięwzięciach IT. - Na co zwrócić uwagę wspierając warsztat metodyczno - narzędziowy Analityka Biznesowy technikami obiektowymi. - Jakich rezultatów można się spodziewać po zastosowaniu technik obiektowych w przedsięwzięciu IT. POWINIENEŚ WIEDZIEĆ - Po kilkudziesięciu latach tworzenia na całym świecie systemów informatycznych - to właśnie od nas zależy, czy dochodzić do pewnych wniosków „na nowo”. Czy raczej wykorzystywać w teraźniejszej pracy, również doświadczenie i wnioski innych osób i organizacji. - Sposób prowadzenia prac przez Inżynierów Oprogramowania, w tym analityków, powinien zostać uzależniony od właściwości konkretnego przedsięwzięcia IT. Które z kolei cechują się różną m.in. organizacją, dojrzałością procesów wytwórczych, środowiskiem wytwarzania. - Analityk Biznesowy powinien dostosowywać swój warsztat metodyczno - narzędziowy do przedsięwzięcia IT w którym uczestniczy. - Metody pracy zaczerpnięte bezpośrednio ze szkoleń, literatury, publikacji należy konfrontować nie tylko z możliwością ale i z sensem ich zastosowania w konkretnym przedsięwzięciu IT. Jaki był cel powstania artykułu ? Powszechnie wiadomo, że proces produkcji oprogramowania jest nakłado i czasochłonny. Im większe jest przedsięwzięcie tym wykorzystanie praktyk Inżynierii Oprogramowania staje się trudniejsze. Nie tylko z powodu samej wiedzy na ich temat, ale przede wszystkim umiejętnemu ich wykorzystaniu w konkretnym projekcie w którym są prowadzone poszczególne prace. Analiza Biznesowa, jest właśnie jedną z tych szczególnych dyscyplin Inżynierii Oprogramowania, gdzie problemy z zastosowaniem praktyk Inżynierii Oprogramowania przekładają się nie tylko na same produkty analityczne ale i całą resztę pracy projektantów, programistów, testerów. A więc projekt, implementację, testy, wdrożenie i oczywiście sam produkt. Którego jakość czy też funkcjonalność będzie szczegółowo obserwowana przez klienta - przyszłego użytkownika przez cały okres jego eksploatacji. Dlatego, każdy powinien sobie odpowiedzieć samodzielnie na pytanie przez pryzmat własnej firmy, projektu, doświadczeń - czy warto posiadać wiedzę jak praktycznie i sensownie wspierać warsztat metodyczno - narzędziowy Analityka Biznesowego praktykami Inżynierii Oprogramowania ? Wpływ czynników ekonomicznych na zastosowanie praktyki Inżynierii Oprogramowania na stanowisku pracy Analityk Biznesowy. Niewiele jest takich środowisk pracy, które byłyby niezależne od czynników ekonomicznych. To właśnie rynek i wszelkie aspekty z nim powiązane rzutują również i na zastosowanie praktyk Inżynierii Oprogramowania. I zapewne każdy z czytających zastanawia się co dokładniej może wpływać na pracę Analityka Biznesowego. Bo odpowiedź na to pytanie mogłaby wyjaśnić - jakie techniki i metody wykorzystywać na stanowisku Analityka. Czy też jak je wykorzystywać oraz w którym kierunku rozwijać własne kompetencje. Międzynarodowa organizacja Analityków Biznesowych IIBA (International Institute of Business Analysis) sugerując się zapewne wieloma opiniami w tym zakresie, zdefiniowała tzw. obszary wiedzy i kompetencji, z którymi każdy pełniący obowiązki Analityka Biznesowego jest związany. Podręcznik BABOK (Business Analysis Body of Knowledge) dosyć precyzyjnie opisuje składowe tych obszarów. Celowo wymieniam te zagadnienia, ze względu na poznanie wytycznych IIBA odnośnie kierunków rozwoju tej specjalizacji jaką jest analiza biznesowa. Które, bo bliższym przyjrzeniu pokazują trud tej pracy w środowisku komercyjnym, z uwzględnieniem praktycznego wymiaru jaki stawia rynek. Obszary tych kompetencji to: - Zaplanowania i monitorowania wykonywanej pracy w ramach całego przedsięwzięcia, aby korzyści z analizy biznesowej były jak największe. Na co mają wpływ tak istotne zagadnienia jak: identyfikacja udziałowców przedsięwzięcia oraz ich wpływu na produkty analityczne, selekcja odpowiednich technik analizy biznesowej, szacowania czasu i kosztu potrzebnej pracy do wykonania, zaplanowania skutecznej metody komunikacji z udziałowcami, zaplanowania sposobu zarządzania wymaganiami, określaniu produktów analitycznych, definiowaniu procesu realizacji prac analitycznych, sposobu oceny postępu pracy. - Skutecznego pozyskiwania wymagań, aby zapewnić w realizowanym przedsięwzięciu ich kompletność, poprawne znaczenie oraz stabilność. Gdzie wyróżnia się różne metody pozwalające na pozyskiwanie tych wymagań. Mianowicie: tzw. burze mózgów, analizowanie dokumentacji, spotkania zespołowe, analizę interfejsów systemowych, przeprowadzanie wywiadów, obserwację udziałowców i przyszłych użytkowników systemu w środowisku wykonywanej przez nich pracy, tworzenie prototypów rozwiązania, przeprowadzanie warsztatów poświęconych wymaganiom, przeprowadzanie ankiet. - Zarządzania wymaganiami i zapewnienie odpowiedniej komunikacji, w rezultacie zastosowania wiedzy której, analityk jest w stanie skutecznie zarządzać wymaganiami, zagadnieniami oraz ich ewentualnymi zmianami. Przyszli użytkownicy systemu i pozostali udziałowcy jednoznacznie identyfikują wymagania i istnieje pomiędzy nimi wspólne stanowisko - dotyczące przyszłej funkcjonalności wytwarzanego systemu. - Przedsiębiorczości podczas analizowania, gdzie zwraca się uwagę również na same czynności wykonywane przez analityka. Które są konieczne do identyfikacji potrzeb biznesowych, problemów, możliwości i ewentualnych rozwiązań. Formułowanie uzasadnienia koniecznych do poniesienia kosztów inwestycji, które są potrzebne w celu dostarczenia rozwiązania. - Analizowanie wymagań to kolejny obszar kompetencji, w którym opisywane są zadania i techniki wykorzystywane przez analityka w celu definiowania rozwiązań spełniających oczekiwania. Wykonywane zadania obejmują takie zagadnienia jak: priorytetowanie wymagań, organizowanie wymagań, specyfikowanie i modelowanie wymagań, definiowania przypuszczeń i ograniczeń, weryfikowanie wymagań, walidowanie wymagań. - Uczestniczenia i walidacji podczas budowy rozwiązania co ma na celu dopilnowanie i zapewnienie, że rozwiązanie zostanie poprawnie zaimplementowane i zostaną spełnione oczekiwania biznesu. Przekrój pojęć mieszczących się tych w/w obszarach kompetencji, wskazuje dosyć obiektywnie na oczekiwany kierunek rozwoju kompetencji oraz środowisko pracy. Które wynikają właśnie z czynników ekonomicznych związanych z pracą wykonywaną na stanowisku analityka. W dalszej części artykułu scharakteryzowano wybrane i przykładowe przedsięwzięcie oraz skutki czynników ekonomicznych na przyjęty warsztat metodyczno narzędziowy - zdefiniowany w metodyce RUP. Scharakteryzowanie pracy i przedsięwzięcia, która wpłynęła na wnioski autora. Aktywne uczestnictwo w przedsięwzięciach informatycznych, gdzie wykonuje się konkretne prace zaplanowane w harmonogramie - poza właściwymi efektami z tej pracy, może przynieść wiedzę o praktycznym zastosowaniu pewnych stosowanych technik Inżynierii Oprogramowania. Produkty, które wytwarza się na etapie Analizy Biznesowej - mogą również być postrzegane w ten sposób. A więc, wnioski z pracy wykonywanej przez osobę, która obejmowała obowiązki Analityka w konkretnym przedsięwzięciu informatycznym - mogą być niezmiernie wartościowe, bowiem nazywają pewne produkty - opisane w tym przypadku przez RUP (Rational Unified Process), z perspektywy praktycznego zastosowania. Podczas realizacji których, obowiązywały w przedsięwzięciu priorytety: 1. Po pierwsze terminy wykonania zadań. 2. Po drugie jakość wykonanej pracy. 3. Po trzecie wpływ wykonanej pracy na losy projektu i możliwe sprzężenia zwrotne. W kolejnych punktach zostaną scharakteryzowane zajęcia wykonywane na stanowisku Analityka. Model wytwórczy, scharakteryzowany przez poniższy rysunek - odzwierciedla ideę wytwarzania systemów wytwórczych. W ramach której, produkty wytwarzane na etapie analizy biznesowej, są przez niniejszy artykuły opisywane. Rys 1.Proces wytwórczy RUP Przed rozpoczęciem opisywania prowadzonych prac, należałoby dokonać interpretacji organizacji pracy w wykorzystywanej metodyce RUP. Tylko właściwa interpretacja, pozwoli w dalszej części artykułu zrozumieć problematykę poruszaną przez artykuł. Przede wszystkim zakłada się proces wytwórczy z grupy podejść ewolucyjnych w wytwarzaniu systemów informatycznych. Proces ten wyróżnia w tym podejściu iteracje i przyrosty systemu, podczas ewolucji prac. Nad całością prowadzonych prac czuwają fazy przedsięwzięcia. Gdzie wymienia się: -Inicjację, -rozwinięcie, -tworzenie, -przejście. Bardzo interesujące w tym podejściu, jest zaangażowanie poszczególnych - skategoryzowanych przez dyscypliny inżynierii oprogramowania, obszarów pracy podczas w/w faz. Gdzie koniecznie należy zrozumieć, że omawiana w tym przypadku analiza biznesowa jest realizowana przede wszystkim w dwóch początkowych fazach przedsięwzięcia, tj. inicjacji oraz rozwinięciu. Kolejne fazy, zakładają wręcz znikome wykorzystanie prac analitycznych dotyczących tzw. biznesu. Należy tu zauważyć - że podczas prac związanych z analizą biznesową identyfikuje i rozpatruje się m.in. wymagania dotyczące systemu. Samo projektowanie systemu, pomimo że rozpoczyna się w fazie inicjacji, to jest realizowane przede wszystkim w fazie kolejnej - rozwinięcia. Czas realizacji projektu, w którym uczestniczył autor niniejszego artykułu - rozciągnięty był na przestrzeni kilku lat. Organizacja przedsięwzięcia, wyłączyła wykonawcę z etapu dotyczącego przygotowywania specyfikacji istotnych warunków zamówienia. Wspominam o tym z tego względu, że pewna podstawowa praca analityczna, została wykonana przed rozpoczęciem prac przez wykonawcę. Jest to właśnie jeden z tych większych problemów, gdzie wykorzystanie tej metodyki - może zostać z góry skazane na niepowodzenie, ze względu na wyłączenie fazy inicjacji poza zasadniczy obszar prac wykonawcy. W rezultacie czego, wykonawca otrzymuje z góry zbiór wymagań systemowych do spełnienia. I co najistotniejsze, bez możliwości metodycznego określenia celów biznesowych. Prace wykonywane przez Analityka wykonawcy w omawianym artykule i harmonogramie, można by było skategoryzować do następujących punktów: 1. udział w spotkaniach z klientem, których celem jest omawianie i doprecyzowanie wymagań, 2. przekładanie, pozyskanych na spotkaniach z klientem informacji, na wiedzę i byty projektowe, 3. realizowanie prac analitycznych i projektowych na podstawie pozyskanej wiedzy, 4. przekazywanie i uzgadnianie produktów analitycznych z pozostałymi członkami zespołu. 5. weryfikacja i konsultacje dotyczące efektów realizacji prac zarówno z członkami zespołu jak i klientem, Niestety, wyżej wymienione obszary prac, z racji pewnej złożoności i sposobu organizacji pracy nie były wystarczająco kontrolowane przez zarząd projektu. Przyjęto taką politykę w projekcie, która polegała na zarządzaniu członkami zespołu a nie bezpośrednimi efektami ich prac. W konsekwencji czego, kolejne etapy cyklu wytwórczego nie opierały się bezpośrednio na dokumentacji specyfikacji analitycznej. Pewne tempo prac oraz brak zdefiniowanej roli w projekcie „Inżynier Procesu Wytwórczego” przyczyniło się m.in. do tego, że zrezygnowano w projekcie na dokładne stosowanie praktyk inżynierii oprogramowania zawartych w RUP. Które pozwoliłyby na rozbijanie zagadnień projektowych na pewne byty - którymi można by było zarządzać. W dalszej części opiszę produkty wytwarzane w rezultacie w/w prac oraz ich skuteczność w tak zorganizowanym projekcie. 1. Udział w spotkaniach z klientem, których celem jest omawianie i pozyskiwanie wymagań. Udział w spotkaniach z klientem, miał na celu na opisywanym etapie wytwórczym: - omawianie wymagań zawartych w SIWZ (Specyfikacji Istotnych Warunków Zamówienia), - pozyskiwanie ewentualnych nowych wymagań, doprecyzowanie wymagań. Rezultatem pracy były przede wszystkim notatki ze spotkań. Dokumenty te, stanowiły podstawę formalną do dalszych prac. Na tym etapie prac, niestety, nie zarządzało się pojęciem „wymaganie” w taki sposób aby: umożliwić na jego dokładną kategoryzacją, umieszczenie w modelu wymagań, czy też udostępnić w bibliotece projektu pozostałym członkom projektu. Bowiem nie istniała taka kultura organizacyjna projektu. Raczej operowano tymi pojęciami w taki sposób, aby uzyskać dobry kontakt z klientem biznesowym. Któremu najczęściej obce jest inżynierskie środowisko pracy. Głównym problemem opisywanego obszaru prac jest zapewnienie takiej organizacji pracy całego zespołu, aby powiązać oczekiwania dwóch odmiennych środowisk pracy: klienta i wykonawcy. 2. Przekładanie, pozyskanych na spotkaniach z klientem informacji, na wiedzę i byty projektowe. Ustalono, że metodyka RUP, po pewnej adaptacji - pozwoli na właściwe wytwarzanie produktów w tym obszarze prac. Popularna technika przypadków użycia, niezmiernie wartościowa w celu dokumentowania oczekiwań klienta od systemu - nie spotkała się jednak z dużym uznaniem przez projektantów i programistów ze względu na pewne problemy. Które można podsumować do punktów: Trudności w prezentowaniu przypadków użycia na takim poziomie abstrakcji, który z jednej strony byłby zrozumiały przez klienta a z drugiej w sposób wręcz inżynierski opisywał użycie systemu informatycznego. Formułowanie przypadków obrazujących tzw. cel aktora, w złożonym systemie spotkał się z pewnym trudem. Wymagał bowiem jeszcze długiej pracy (poza uzgodnieniami z klientem), która miałaby na celu doprecyzować i rozbić scenariusze na takie porcje informacji - które były efektywnie rozumiane i implementowane przez zespół programistów. Brak statycznej perspektywy funkcjonalności opisanej przez przypadki użycia - przyczynił się do scalenia modeli analitycznych dopiero na kolejnych etapach wytwórczych: projektowaniu i implementacji. W konsekwencji czego, problemy tam zauważone skutkowały często: ponowieniem prac nad samymi przypadkami użycia, które były zaakceptowane przez klienta, angażowaniem projektantów i programistów do prac analitycznych (kosztem ich czasu przewidzianego do prac głównie związanych z projektowaniem i implementacją). Reasumując praca dotycząca przekładania pozyskanych na spotkaniach z klientem informacji na wiedzę i byty projektowe - powinna nie tylko być właściwa. Wymaga również wzajemnej świadomości pracy do wykonania przez obie strony: klienta i wykonawcy. 3. Przekazywanie i uzgadnianie produktów analitycznych z pozostałymi członkami zespołu. Przekazywanie prac do pozostałych członków zespołu odbywało się poprzez bezpośrednią rozmowę, na potrzeby której organizowano często spotkania. Ponadto dyskutowano z wykorzystywaniem wszystkich dostępnych mediów komunikacji (telefon, e-mail, telekonferencje). Podczas rzeczywistych prac - członkowie zespołu byli skłonni do dyskusji bezpośrednich z pominięciem tzw. dokumentacji. Co nawiązuje zasadniczo do idei „manifestu zwinnego wytwarzania oprogramowania” oraz wpływa negatywnie na ideę wykorzystywania zunifikowanego języka modelowania UML - który z założenia pozwala na jednoznaczną komunikację osobom posiadającym różne kompetencje. Ponadto specyfikacja prac analitycznych, które były nastawione na środowisko współpracy z klientem - nie koniecznie dostarczała rezultatów pracy oczekiwanych przez projektantów i programistów. Specyfikacja przypadków użycia nastawiona na klienta, brak perspektywy statycznej - na pewno nie zapewniała stabilnego źródła informacji. Konsekwencją czego, były często długie rozmowy, nie zawsze prowadzące do jednoznacznych wniosków. Zasadniczym problemem pracy związanej z przekazywaniem i uzgadnianiem produktów analitycznych do pozostałych członków zespołu, stanowi głównie zagadnienie przyjęcia efektywnej metody komunikacji i pogodzenia mentalności osób cechujących się różnymi kompetencjami. 4. Weryfikacja i konsultacje dotyczące efektów realizacji prac zarówno z członkami zespołu jak i klientem. Model iteracyjno-przyrostowy, wymaga częstych odbiorów prac zarówno wewnątrz zespołu wykonawcy, jak i przez zamawiającego. Oznacza to, że weryfikacja prac była praktycznie na porządku codziennych obowiązków. Co w praktycznym wymiarze, gdzie klient podczas trwania projektu wykonuje również swoje główne prace (inne od uczestniczenia w projekcie) są obarczone pewnym wyzwaniem dla samego klienta. Można powiedzieć, że z chwilą rozpoczęcia projektu drastycznie zwiększa się dla niego liczba obowiązków. Model iteracyjno - przyrostowy, pomimo dobrych chęci i gwarancji zrozumienia z klientem na płaszczyźnie realizowanych prac projektowych - może wręcz utrudniać główną pracę klienta. Który to, z chwilą nie dysponowania wystarczającą ilością czasu, może wpływać destruktywnie na postęp prac. Zadanie poświęcone weryfikacjom i konsultacjom dotyczącym efektów realizacji prac, zarówno z członkami zespołu jak i klientem, przez pewną pożądaną i właściwą cykliczność - bez pewnych zabiegów dotyczących zmian organizacyjnych - może pogrążać zarówno pracę zasadniczą wykonywaną przez samego klienta jak i realizowany projekt. Dlatego też, należy zwrócić szczególną uwagę na przyjęte metody porozumiewania się podczas ewolucji systemu i towarzyszących temu cyklicznym spotkaniom. Aspekt historyczny Podsumowanie wniosków z zastosowania technik obiektowych na stanowisku analityka biznesowego, można byłoby skonfrontować w pierwszej kolejności ze sprawą fundamentalną. Otóż, jak można wnioskować np. z historii powstania zunifikowanego języka modelowania UML. Który oparty był o wybór najpopularniejszych trzech metodyk (OOAD - Grady Booch, OOSE - Ivar Jacobson, OMT - James Rumbaugh), spośród wielu współzawodniczących ze sobą (lata '80, ' 90). Można zauważyć, że metodyki te opierały się o spostrzeżenie, jak ważną rolę odgrywają w przedsięwzięciach m.in.: - modelowanie dziedziny przedmiotowej, - modelowanie aspektu użytkownika, - modelowanie aspektu projektowania, - modelowanie aspektu implementacji, - modelowanie cyklu życia oprogramowania. Już w pierwszych bardziej złożonych projektach zauważano, że pominięcie w projekcie aspektu modelowania - może niekorzystnie wpłynąć na jego efekt końcowy. Przywołanie takich podstaw historycznych stojących za potrzebą modelowania, powinno zwrócić uwagę na fakt,że bardzo wiele osób na świecie, praktycznie począwszy od pierwszych przedsięwzięć informatycznych dostrzegało potrzebę modelowania. Okres rywalizacji różnych metodyk, czy też wybór międzynarodowego standardu UML tym bardziej podkreśla znaczenie tego faktu. Innymi słowy, artykuł ten nie odkrywa a raczej przypomina o pewnym fakcie. Otóż, inżynier oprogramowania może sam dochodzić do pewnych wniosków, albo poznawać te, które zostały już wcześniej zgromadzone i opisane - najczęściej wiele lat temu. Podsumowanie Po pierwsze już sama organizacja projektu rzutuje na odpowiedni sposób prowadzenia prac analitycznych, w tym wybrania określonej metody stosowania technik obiektowych. W innym przypadku nie tylko projekt nie osiąga założonych pozytywnych rezultatów ale i zniesławione zostają techniki obiektowe, w tym te, które wspierają warsztat analityka biznesowego. Dużą wagę należałoby przywiązać tu do odpowiedzi na pytanie: - jakie znaczenie w projekcie mają efekty z analizy biznesowej? - czy postawiono taki wymóg jakościowy wobec prowadzonych pracach analitycznych, aby projekt dostarczał konkretnych jego składowych - obrazujących aspekt statyczny i dynamiczny ? - czy zdefiniowane oczekiwania od produktów analitycznych, poza samym ich celem zastosowania, uwzględniają środowisko pracy i jego właściwości? Miejąc tu na uwadze takie zagadnienia jak: - proces wytwarzania oprogramowania i jego dojrzałość, - przyszłą konserwację oprogramowania będącego użyciu, - ewentualną integrację oprogramowania, - sprawność i efektywność produkcji oprogramowania bez uszczerbku dla jakości, - czy organizacja projektu umożliwi na taką realizację prac analitycznych aby osiągnąć ich założony cel? Jak wynika ze scharakteryzowanego w niniejszym artykule przykładowego projektu, skutki zastosowania określonych technik obiektowych mogą być zarówno pozytywne jak i negatywne. Co jest zasadniczo związane ze sprawami poruszonymi przez w/w pytania. Doświadczenie z projektu pokazują, że w konsekwencji nie podjęcia decyzji dotyczących w/w zagadnień, mogą powstać konkretne wyzwania - których pominięcie bezpośrednio może doprowadzić do klęski pracy. Wymienia się tu: - organizacja projektu, powinna zapewnić sprawne zarządzanie projektu zarówno przez zamawiającego jak i wykonawcę, - zarówno zamawiający jak i wykonawca powinni być świadomi skutków podjętych decyzji podczas zbierania wymagań, - wybór odpowiedniej metody komunikacji w projekcie powinien zapewnić odpowiedni poziom komunikacji osobom o różnych kompetencjach jak i mentalności, - organizacja przedsięwzięcia i przebiegu projektu, powinna uwzględnić również i wszelkie aspekty poza projektowe osób i organizacji uczestniczących w przedsięwzięciu. Scharakteryzowana wcześniej praca i projekt, na pewno powinna skłonić do zastanowienia i odpowiedzi na pytanie: czy w mojej firmie i projekcie chciałbym podjąć się działań zmierzających do zminimalizowania opisywanych w tym artykule problemów? W pierwszej kolejności, scharakteryzuję w tym celu korzyści płynące z wprowadzenia określonych i uzasadnionych metod na stanowisku analityka, tj.: - wykonawca poznaje cele biznesowe organizacji oraz potrzeby pracowników i innych udziałowców, - wykonawca rozumie jaka oczekiwana funkcjonalność systemu i wymagania systemowe, byłyby w stanie umożliwić na osiąganie zdefiniowanych celów i potrzeb biznesowych, - wykonawca jest świadomy sposobu przyszłego wykorzystania systemu i ewentualnych zmian organizacyjnych z chwilą rozpoczęcia jego eksploatacji, - klient poznał proces wytwórczy realizowanego przedsięwzięcia na tyle, aby świadomie współpracować z wykonawcą i rozumieć konsekwencje współpracy i następstw podejmowanych decyzji, - klient jest pewny że zarejestrowane przez wykonawcę wymagania są zgodne z jego oczekiwaniami, - współpraca klienta z wykonawcą przekłada się bezpośrednio na pierwszą inżynierską postać systemu, zapoznanie klienta z efektami tej pracy zmniejsza ryzyko ewentualnego niezrozumienia pomiędzy pierwszym etapem dyskusji na temat wymagań a projektem samego systemu, - przyjęta metoda komunikacji nie budzi żadnych zastrzeżeń w kontekście jednoznacznego zrozumienia pomiędzy wszystkimi członkami zespołu, efektywność komunikacji potwierdza jej skuteczność, - problem dysponowania odpowiednią ilością czasu pomiędzy osobami wyznaczonymi do przeglądów kolejnych postaci systemu, rozwiązuje precyzyjna ewolucja systemu, co w rezultacie minimalizuje czas i trud związany z akceptacją, O autorze artykułu: Artur Machura zajmuje się dyscypliną inżynierii oprogramowania Analiza Biznesowa na dwóch płaszczyznach jej postrzegania, tj. - poprzez uczestniczenie w przedsięwzięciach IT i projektach budowy systemów informacyjnych oraz informatycznych - podejmując się głównie roli Analityka, - prowadząc działalność badawczo - rozwojową poświęconą ekonomicznemu uzasadnieniu stosowania praktyk Inżynierii Oprogramowania w przedsięwzięciach IT. Wśród których zwraca szczególną uwagę na te, które mają największe znaczenie w prowadzonych przez niego pracach analitycznych. A więc zarządzanie projektami i procesami wytwarzania oprogramowania oraz metod i narzędzi wspierających warsztat analityczny w przedsięwzięciach IT. Wynikiem prowadzonej przez niego działalności są: - umiejętność dostosowywania i budowania produktów analitycznych, spełniających określone potrzeby firmy i realizowanych przedsięwzięć informatycznych, - publikacje mające na celu podsumowanie wybranych doświadczeń zawodowych oraz wyników badań dotyczących Inżynierii Oprogramowania, - prowadzenie szkoleń powiązanych z dyscypliną Inżynieria Oprogramowania - Analiza Biznesowa. Kontakt z autorem: e-mail: artur.machura (at) uml.com.pl, tel. 501-176-256 |
| Indeks :: Drukuj :: E-mail |
Komentarze są własnością ich autorów. Nie ponosimy odpowiedzialności za ich treść.
