Temat: Analitycy biznesowi...

Chciał bym usłyszeć opinię osób które na co dzień stykają się z tym zawodem w odniesieniu do materiału który zamieściłem w opisie grupy.

Proszę się nie krępować :PŁukasz Lipiński edytował(a) ten post dnia 03.04.08 o godzinie 09:28

Temat: Analitycy biznesowi...

Łukasz Lipiński:
Chciał bym usłyszeć opinię osób które na co dzień stykają się z tym zawodem w odniesieniu do materiału który zamieściłem w opisie grupy.

Proszę się nie krępować :PŁukasz Lipiński edytował(a) ten post dnia 03.04.08 o godzinie 09:28

Opinie na temat trafności opisu czy zapotrzebowania? :)

Moje doświadczenie mówi, że (pół żartem ale i pół serio): klienci sa nieedukowalni, najlepszymi klientami (wyedukowanymi) są ci co zaliczyli porażke wdrożenia systemu u siebie, ktoś kiedys powiedziedział "nie święci garnki lepią" i teraz każdy uważa ze jest analitykiem lub będzie nim po dwudniowym szkoleniu.

:)

Temat: Analitycy biznesowi...

Na temat zapotrzebowania to będzie coraz większe, a co do trafności no to już wy (Analitycy) musicie się wypowiedzieć.

Ciężko być analitykiem po dwudniowym szkoleniu jeśli klient wymaga od osoby na tym stanowisku żeby znała:

znajomość technologii JEE, .Net, znajomość systemów baz danych,
minimum 3-letnie doświadczenie,
doświadczenie zawodowe w programowaniu i/lub projektowaniu systemów komputerowych, znajomość notacji UML.
do tego
Analiza procesów biznesowych klientów oraz potrzeb i potencjalnych kierunków rozwoju oprogramowania
Udział w spotkaniach biznesowych i handlowych
Udział w pracach projektowych w zakresie architektury systemów oraz wymagań funkcjonalnych dla tworzonego oprogramowania
Analiza istniejących rozwiązań informatycznych

to tak na przykładzie projektu który obecnie prowadzę ...

Temat: Analitycy biznesowi...

Łukasz Lipiński:
Na temat zapotrzebowania to będzie coraz większe, a co do trafności no to już wy (Analitycy) musicie się wypowiedzieć.

Ciężko być analitykiem po dwudniowym szkoleniu jeśli klient wymaga od osoby na tym stanowisku żeby znała:

znajomość technologii JEE, .Net, znajomość systemów baz danych,
minimum 3-letnie doświadczenie,
doświadczenie zawodowe w programowaniu i/lub projektowaniu systemów komputerowych, znajomość notacji UML.
do tego
Analiza procesów biznesowych klientów oraz potrzeb i potencjalnych kierunków rozwoju oprogramowania
Udział w spotkaniach biznesowych i handlowych
Udział w pracach projektowych w zakresie architektury systemów oraz wymagań funkcjonalnych dla tworzonego oprogramowania
Analiza istniejących rozwiązań informatycznych

to tak na przykładzie projektu który obecnie prowadzę ...

Wszystko jest OK ale: analityk powinien się trzymać z daleka od impelementacji (programowanie) ale też powinien doskonale znać modele implemetacyjne (wzorce projektowe). J2EE, EJB czy .NET, COM+ itp. to modele obiektowe, komponentowe oraz elementy inżynierii oprogramowania, kóre analityk powinien doskonale rozumieć, nie musi mieć doświadczenia w ich użyciu.

Obecnie wśród ról w projektach IT widze, nie tylko ja, dwie role i dwa etapy:
- analityk biznesowy: wykonuje analizę i projektuje model części systemu specyficznej dla dziedizny (model dziedziny systemu i specyfike GUI), stanowi to specyfikację systemu (a nie tylko bzdetne i mylące use casy)
- inżynier systemowy architekt: na bazie specyfikacji systemu opracowuje docelowy kształt systemu i jego implementację.

Razem do końca projektu sprawują nadzór merytoryczny nad projektem jako wsparcie dla kierownika projektu, typowego PM'a.

Jako duży błąd w takich projektach postrzegam zlecanie analiz programistom, nawet doświadczonym ale bez przygotowania i doświadczenia z zakresu zarzadządzania i marketingu.

Ja zadam też pytanie: na ile ma sens i jest potrzeba angażowania takiego analityka na full time skoro ma robotę na maks. 20% czasu projektu?

Temat: Analitycy biznesowi...

Jarosław �.:

Ja zadam też pytanie: na ile ma sens i jest potrzeba angażowania takiego analityka na full time skoro ma robotę na maks. 20% czasu projektu?

Moim zdaniem wszytko zależy od tego jakiej osoby potrzebuje firma bo bardzo często zdarza się, że chcą oni osobę, która jest najczęściej doświadczona jeśli chodzi o programowanie/projektowanie i dążą do tego aby zrobić z niej właśnie Analityka Biznesowego.

Inżynier systemowy architekt zostaje w tym przypadku właśnie taką osobą. I to on zaczyna przejmować rolę Analityka która przeprowadza analizę u klienta od strony biznesowej.

Według mnie często jest tak, ponieważ mniejszych firm nie stać na to aby były u nich 2 osoby, jedna zajmująca się analizą biznesową a druga zajmująca się architekturą. Przy tym oszczędzają te 80% czasu, która pozostaje Analitykowi biznesowemu zatrudnionemu na full time.
Jeśli się mylę wyprowadź mnie z błędu.

Temat: Analitycy biznesowi...

Łukasz Lipiński:
Moim zdaniem wszytko zależy od tego jakiej osoby potrzebuje firma bo bardzo często zdarza się, że chcą oni osobę, która jest najczęściej doświadczona jeśli chodzi o programowanie/projektowanie i dążą do tego aby zrobić z niej właśnie Analityka Biznesowego.

I tu jest "droga do klęski" :) były programista analityk biznesowy nie mający pojęcia o analizie strategicznej informatyzowanej firmy.

Inżynier systemowy architekt zostaje w tym przypadku właśnie taką osobą. I to on zaczyna przejmować rolę Analityka która przeprowadza analizę u klienta od strony biznesowej.

Jak wyżej.

Według mnie często jest tak, ponieważ mniejszych firm nie stać na to aby były u nich 2 osoby, jedna zajmująca się analizą biznesową a druga zajmująca się architekturą. Przy tym oszczędzają te 80% czasu, która pozostaje Analitykowi biznesowemu zatrudnionemu na full time.

:)

Jeśli się mylę wyprowadź mnie z błędu.

To tak jak by ktoś (tamte firmy) uznał, że doświadczony kierownik projektów, realizujący wiele zawartych umów, mógł zastąpić w firmie prawnika..... i oszczędzić te 80%....

Statystyki pokazują, że 84% projektów IT to porażki (niedotrzymane budżety, terminy itp.) w 100% tych przypadków PMowie podają źle określone wymagania jako główne źródło problemu. Szukam przyczyny (nie ja jeden) i postrzegam tu właśnie kłopot.

Ostatnio widziałem inną statystykę: Polskie firmy ponad 10krotnei rzadziej angażują prawników niż firmy zachodnie, jakość zawieranych umów w Polsce jest podobno żenująca. Co do analityków uważam, nie ja jeden, ze jest podobnie: jakość dokumentów wymagań na systemy IT jest żenująca.

Przykłady? opis systemu o wartości ok. 15 mln PLN pewna duża firma IT (giełdowa! czyli podobno profesjonaliści) wykonała w postaci prozy na ok. 200 str. w tym trzy obrazki. Wykonali ją ich analitycy biznesowy... bez komentarza.

Wyobraźcie sobie teraz budowę o rząd tańszego domku prowadzoną na bazie tekstowego opisu bez rysunków. Takich przykładów są setki....

Znam też projekty prowadzone porządnie, z dokumentacją w postaci modeli i w 100% jednoznaczną. Efekt: czas wdrożenia średnio krótszy o 30%, liczba prototypów trzy a nie dziesiątki.

Firma, nie ważne IT czy ich klient, nie zleci w Polsce pracy analitykowi bo to kosztuje (ok. 20% budżetu projektu) co nie przeszkadza im przekroczyć budżet o nawet 300% z powodu źle określonych wymagań i niekończących się poprawek.

Polecam:
http://download.theiiba.org/files/venpres/TheTopTenSki...

http://download.theiiba.org/files/BOKV1_6.pdf

P.S.
Najlepszymi moimi klientami sa te firmy, które umoczyły porządnie w poprzednim projekcie albo właśnie proszą o ratowanie obecnego..:) oni już doskonale wiedzą do czego służa prawnicy i analitycy ... (a nie programiści)...

Analityk biznesowy powinien umieć opracowac model biznesowy swojego klianta, wskazać cel projektu IT, ocenić jego próg rentownosci i zakres, opracować model dziedziny systemu (lub diagram ERD) i przekazać wykonawcy do implementacji kompletną analizę obiektową organizacji klienta w wersji analitycznej.

Temat: Analitycy biznesowi...

Jarosław �.:

Łukasz Lipiński:
Moim zdaniem wszytko zależy od tego jakiej osoby potrzebuje firma bo bardzo często zdarza się, że chcą oni osobę, która jest najczęściej doświadczona jeśli chodzi o programowanie/projektowanie i dążą do tego aby zrobić z niej właśnie Analityka Biznesowego.

I tu jest "droga do klęski" :) były programista analityk biznesowy nie mający pojęcia o analizie strategicznej informatyzowanej firmy.

Inżynier systemowy architekt zostaje w tym przypadku właśnie taką osobą. I to on zaczyna przejmować rolę Analityka która przeprowadza analizę u klienta od strony biznesowej.

Jak wyżej.

Według mnie często jest tak, ponieważ mniejszych firm nie stać na to aby były u nich 2 osoby, jedna zajmująca się analizą biznesową a druga zajmująca się architekturą. Przy tym oszczędzają te 80% czasu, która pozostaje Analitykowi biznesowemu zatrudnionemu na full time.

:)

Jeśli się mylę wyprowadź mnie z błędu.

To tak jak by ktoś (tamte firmy) uznał, że doświadczony kierownik projektów, realizujący wiele zawartych umów, mógł zastąpić w firmie prawnika..... i oszczędzić te 80%....

Statystyki pokazują, że 84% projektów IT to porażki (niedotrzymane budżety, terminy itp.) w 100% tych przypadków PMowie podają źle określone wymagania jako główne źródło problemu. Szukam przyczyny (nie ja jeden) i postrzegam tu właśnie kłopot.

Ostatnio widziałem inną statystykę: Polskie firmy ponad 10krotnei rzadziej angażują prawników niż firmy zachodnie, jakość zawieranych umów w Polsce jest podobno żenująca. Co do analityków uważam, nie ja jeden, ze jest podobnie: jakość dokumentów wymagań na systemy IT jest żenująca.

Przykłady? opis systemu o wartości ok. 15 mln PLN pewna duża firma IT (giełdowa! czyli podobno profesjonaliści) wykonała w postaci prozy na ok. 200 str. w tym trzy obrazki. Wykonali ją ich analitycy biznesowy... bez komentarza.

Wyobraźcie sobie teraz budowę o rząd tańszego domku prowadzoną na bazie tekstowego opisu bez rysunków. Takich przykładów są setki....

Znam też projekty prowadzone porządnie, z dokumentacją w postaci modeli i w 100% jednoznaczną. Efekt: czas wdrożenia średnio krótszy o 30%, liczba prototypów trzy a nie dziesiątki.

Firma, nie ważne IT czy ich klient, nie zleci w Polsce pracy analitykowi bo to kosztuje (ok. 20% budżetu projektu) co nie przeszkadza im przekroczyć budżet o nawet 300% z powodu źle określonych wymagań i niekończących się poprawek.

Polecam:
http://download.theiiba.org/files/venpres/TheTopTenSki...

http://download.theiiba.org/files/BOKV1_6.pdf

P.S.
Najlepszymi moimi klientami sa te firmy, które umoczyły porządnie w poprzednim projekcie albo właśnie proszą o ratowanie obecnego..:) oni już doskonale wiedzą do czego służa prawnicy i analitycy ... (a nie programiści)...

Analityk biznesowy powinien umieć opracowac model biznesowy swojego klianta, wskazać cel projektu IT, ocenić jego próg rentownosci i zakres, opracować model dziedziny systemu (lub diagram ERD) i przekazać wykonawcy do implementacji kompletną analizę obiektową organizacji klienta w wersji analitycznej.

I dokładnie o takie opinie mi chodzi :]

Temat: Analitycy biznesowi...

Witam

To moja pierwsza wypowiedź, jednak chciałbym się ustosunkować do opisu analityka podanego w opisie tej grupy.
Otóż analityk zajmujący się analizowaniem danych bynajmniej nie jest analitykiem IT. To analityk biznesowy (bez IT w nazwie), albo wręcz analityk w ogóle (nadal bez IT).
Mówiąc o analizie IT powinniśmy zdefiniować kilka obszarów i optymalnie ograniczyć się do jednego. Obszary jakie ja widzę to:

1. Analizowanie i usprawnienie procesów organizacji
2. Zbieranie informacji od zamawiającego/przyszłego użytkownika oprogramowania i przekładanie tego na precyzyjne wymagania
3. Opracowanie precyzyjnych wymagań i powiązanie ich z konkretną technologią
4. Kodowanie (tworzenie kodu, programowanie)
5. Testowanie
6. Utrzymanie, administracja oprogramowaniem, poprawa wydajności i błędów

Teraz zaczynając od dołu:
6. To są role typowo informatyczne. Wprawdzie pojawiają się tu stanowiska takie jak analityk systemowy (osoba odpowiedzialna za analizę działającego oprogramowania, usprawnienie pracy, wykrywanie nieprawidłowości), czy analityk baz danych (j.w., ale dla baz danych), to zdecydowanie nie umieszczałbym ich w zakresie analizy IT. Inne stanowiska występujące w tym obszarze to m.in. administrator baz danych, administrator aplikacji, administrator systemów operacyjnych itp.
5. Rola wiążąca się z utrzymaniem jakości oprogramowania, choć wymaga analizowana informacji, to są to informacje z tworzonego systemu. Nie zaliczałbym tego do analizy IT (aczkolwiek analityk IT może też pełnić rolę testera). Najczęstsze stanowiska to tester oprogramowania.
4. Tworzenie kodu jest niemal mechanicznym przełożeniem projektu na język zrozumiały dla komputera. Rola, z całym szacunkiem, wytwórcza. Zdecydowanie nie powinno tu być miejsca na analizę. Za to jak najbardziej na najlepsze wykorzystanie warsztatu programistycznego. Stanowiska - programista (często z określeniem języka/języków), deweloper.
3. Przełożenie wymagań na technologię zaczyna ocierać się o analizę IT. Jednak tak naprawdę praca analityczna senso stricte powinna się zakończyć przed tym etapem. Tu chodzi o konkretne rozwiązania. Raczej nie analiza IT. Stanowiska - projektant IT/oprogramowania, architekt IT/oprogramowania
2. To jest właśnie kluczowa część analizy IT. Osoba pełniąca tą rolę pośredniczy między dwoma światami - posiadającym ogólne, często intuicyjne zrozumienie "biznesem" i oczekującym precyzji komputera światem informatyków. Tu odbywa się zebranie wymagań, analiza mająca na celu odróżnienie faktycznych potrzeb od pobożnych życzeń, oraz odnalezienie niespójności (czym może być to coś czego może nie być). Dzięki temu rozmyte oczekiwania biznesu przekłada się na szczegółowy i precyzyjny opis "komputerowy" zrozumiały dla informatyka. Typowa analiza IT. Co ciekawe mamy tu mnogość stanowisk, wśród nich: analityk biznesowy IT (czasem IT jest niedopowiedziane, ale wynika z listy oczekiwań i zadań), analityk funkcjonalny, analityk systemowy (ale rola skoncentrowana na zbieraniu wymagań a nie analizowaniu systemu) czy też po prostu analityk IT. W angielskim ogłoszeniach często pojawia się coś takiego: "being a liasion between business and IT team". Myślę też, że częściowo mieści się tu też konsultant IT. Czasem etap ten dzieli się na składowe (analiza biznesowa i funkcjonalna/systemowa), a czasem traktuje jako całość. Ja osobiście jestem zwolennikiem traktowania tego etapu jako jeden, choć aktualnie pracuję jedynie w części "szczegółowej" (czyli analityk funkcjonalny, co de facto i tak wymusza dokonanie analizy biznesowej wcześniej).
1. Analizowanie jak działa organizacja i co poprawić. Nie ociera się w ogóle o analizę IT, aczkolwiek wnioskiem może być konieczność wdrożenia rozwiązań informatycznych :-) Tą część IMHO opisuje podany opis grupy (a powinien opisywać 2). Nazwy stanowisk: analityk biznesowy (nigdy nie pojawia się tu IT w nazwie), analityk danych.

Pozdrawiam

Temat: Analitycy biznesowi...

Tomasz Miodek:

2. Zbieranie informacji od zamawiającego/przyszłego użytkownika oprogramowania i przekładanie tego na precyzyjne wymagania
3. Opracowanie precyzyjnych wymagań i powiązanie ich z konkretną technologią

W zasadzie mam podobne podejście co do całości wypowiedzi, czy mógłbyś jednak wyspecyfikować różnicę pomiędzy czynnością "przekładanie tego na precyzyjne wymagania" z pkt. 2, a "Opracowanie precyzyjnych wymagań" z pkt. 3?

Pozdrawiam

Temat: Analitycy biznesowi...

.Monika Brocka edytował(a) ten post dnia 26.07.10 o godzinie 14:20

Temat: Analitycy biznesowi...

Monika Brocka:

3. Opracowanie precyzyjnych wymagań i powiązanie ich z konkretną technologią
4. Kodowanie (tworzenie kodu, programowanie)
5. Testowanie
6. Utrzymanie, administracja oprogramowaniem, poprawa wydajności i błędów

Z tymi punktami kompletnie się nie zgadzam.
3. Analityk nie jest od wskazywania rozwiązania architektonicznego,bo to działka Architekta :)
4. Kodowanie? Pierwsze słyszę, aby Analityk kodował, no chyba, że stanowisko analityka zostało powiązane ze stanowiskiem programisty.
5. Testowanie- ja tutaj przychyliłabym się do stwierdzenia: Pisanie scenariuszów testowych"- w tym jeszcze mogę się zgodzić.

6. Kompletna pomyłka. Administracja? To czym w takim razie zajmuje się administrator?

Polecam _czytanie_ze_zrozumieniem_ :)

Temat: Analitycy biznesowi...

Może to da co nieco to zastanowienia: skuteczność przekazywania informacji - od tyłu:
- programista potrzebuje dokumentację implementacyjną
- autor implementacji potrzebuje wymagania na oprogramowanie

wymagania MUSZĄ być jednoznaczne aby mogła powstać ostateczna "dobra" dokumentacja implementacyjna a co zrobić by taka była? Wykonać prototyp koncepcji rozwiązania ten jednak może zrobić tylko ten kto doskonale zna (zrozumiał) zamawiającego bo to jemu należy rozwiązać problem, dlatego moim zdaniem w IIBA i nie tylko kładzie się nacisk na to, by AB oddawał nie prozę jako wymagania a właśnie specyfikację przyszłego systemu czyli jego koncepcję, ta zaś to:
- model dziedziny systemu (czyli byty biznesowe i ich biznesowe atrybuty i metody)
- przypadki użycia wraz z prototypami ekranów oraz scenariuszami jak obiekty dziedzinowe realizują te przypadki
- model procesowy, który stanowi dla tego wszystkiego kontakt oraz model testów (scenariusze testowe)

Architekt systemu ma ubrać to w konkretne technologie (frameworki, język programowanie, sprzęt, sieć itp. by zrealizować wymagania pozafunkcjonalne i napisać koderom co mają wykonać).

Jedynym sposobem na przekazanie wymagań dla murarzy jest narysowanie im co ma powstać, szczegóły (rurki z PVC czy z Miedzi) to już kwestia dokumentacji wykonawczej ale wymagania inwestora dla developera to nie jest PROZA.

Jeżeli jakiś analityk nie potrafi oddać dokumentacji zawierającej po protu opis koncepcji systemu spełniającego biznesowe wymagania zamawiającego to i tak nie ma od tego ucieczki, ktoś to zrobi pytanie w ilu iteracjach.... nie sądzę by była to fucha architekta systemu, który nie był u klienta i nie rozumie jego potrzeb (to że się domyśla to za mało).

Tak wiec mamy trzy etapy:
- analiza wymagań - opracowanie koncepcji rozwiązania
- opracowanie projektu implementacji
- implementacjaJarek Żeliński edytował(a) ten post dnia 26.07.10 o godzinie 15:35

Temat: Analitycy biznesowi...

Joanna U.:

Tomasz Miodek:
2. Zbieranie informacji od zamawiającego/przyszłego użytkownika oprogramowania i przekładanie tego na precyzyjne wymagania
3. Opracowanie precyzyjnych wymagań i powiązanie ich z konkretną technologią

W zasadzie mam podobne podejście co do całości wypowiedzi, czy mógłbyś jednak wyspecyfikować różnicę pomiędzy czynnością "przekładanie tego na precyzyjne wymagania" z pkt. 2, a "Opracowanie precyzyjnych wymagań" z pkt. 3?

Pozdrawiam

Być może źle się wyraziłem. Chodzi o to, co kto ma "na wejściu" i "na wyjściu". Dla analityka biznesowego "wejściem" jest to co usłyszy od biznesu (wliczając oczywiście wszystkie odpowiedzi na jego pytania, sztuką jest tak pytać, aby uzyskane odpowiedzi dały kompletny obraz), wyjściem zaś spójne i kompletne formalne wymagania.
Dla architekta/projektanta wejściem są spójne i kompletne formalne wymagania, zaś wyjściem szczegółowa struktura programu (klasy, struktura bazy danych, rozbicie GUI na poszczególne elementy itp.). Żeby nie było wątpliwości - już na etapie analizy pojawiają się sygnały, że np. potrzebne będą konkretne klasy. Jednak to architekt nadaje im ostateczny kształt, często rozbudowuje, dzieli, wreszcie dopasowuje do możliwości konkretnego rozwiązania, które zostanie użyte (wiadomo, że różne problemy różnie rozwiązuje się w konkretnych technologiach, jako przykład podam choćby wielodziedzicznie), określa słowniki itp.. Problem w tym, że architekt nadal opracowuje to co dostał, ale robi to właśnie po to, żeby powiązać wymagania z technologią.

Temat: Analitycy biznesowi...

Tomasz Miodek:
Być może źle się wyraziłem. Chodzi o to, co kto ma "na wejściu" i "na wyjściu". Dla analityka biznesowego "wejściem" jest to co usłyszy od biznesu (wliczając oczywiście wszystkie odpowiedzi na jego pytania, sztuką jest tak pytać, aby uzyskane odpowiedzi dały kompletny obraz), wyjściem zaś spójne i kompletne formalne wymagania.

Tu pozwolę sobie na polemikę,

wejściem dla analityka (lepiej dla wyniku analizy) jest twardy materiał w postaci dokumentów jakie są przetwarzane, opowieści mogę uzupełnić je ale nie powinny stanowić głównego materiału "badawczego". Osobiście traktuję "odpowiedzi na pytania" jako materiał wysokiego ryzyka co potwierdzają moje nie tylko moje obserwacje. Zachęcam do "odtwarzania" opisu firmy (jakiejkolwiek organizacji) z tego co pisze (partia przykładowych dokumentów). Można z małym błędem uznać, że istotne są w firmach te informacje, które są utrwalane.

Co do sztuki zadawania pytań potwierdzam, że jest "sztuką" ale same pytania mają jedną wadę: jak ktoś jakiejś informacji nie chce udzielić to jej nie udzieli, jeżeli uzna, że podanie zafałszowanej informacji pozwoli komuś coś "ugrać" to uczyni to. Należy zawsze pamiętać, że zleceniodawcą analityka jest sponsor projektu a nie przyszły użytkownik (który może mieć inny cel niż jego pracodawca). Klasycznym przykładem są systemy raportowania ale także przypadki, w których dane są kolekcjonowane. Nie zmienia to faktu, że na etapie wywiadów przydaje się psychologia komunikacji i wiedza o tym jak przesłuchują policjanci (pisze to bardzo poważnie, ale nie mam na myśli tej śmiesznej lampki w oczy;))).

Dla architekta/projektanta wejściem są spójne i kompletne formalne wymagania, zaś wyjściem szczegółowa struktura programu (klasy, struktura bazy danych, rozbicie GUI na poszczególne elementy itp.). Żeby nie było wątpliwości - już na etapie analizy pojawiają się sygnały, że np. potrzebne będą konkretne klasy. Jednak to architekt nadaje im ostateczny kształt, często rozbudowuje, dzieli, wreszcie dopasowuje do możliwości konkretnego rozwiązania, które zostanie użyte (wiadomo, że różne problemy różnie rozwiązuje się w konkretnych technologiach, jako przykład podam choćby wielodziedzicznie), określa słowniki itp.. Problem w tym, że architekt nadal opracowuje to co dostał, ale robi to właśnie po to, żeby powiązać wymagania z technologią.

Formalne czyli w jakiej postaci?

Model klas (model dziedziny) powinien wyjść już od analityka bo tylko "był między ludźmi" i wie co tam się dzieje.

Co do wielodziedziczenia (w ogóle dziedziczenia) to generalnie w modelu dziedziny należy go unikać (ja nie stosuję w ogóle) bo po pierwsze:
- model dziedziny to nie model pojęciowy a model rzeczywistych utrwalanych bytów i powiązań między nimi (ale nie jest to baza danych!)
- w realnych warunkach otaczające nas przedmioty i osoby niczego nie dziedziczą a są co najwyżej pewnym agregatami, każdy utrwalany obiekt w bazie reprezentuje fizyczny byt lub zdarzenie więc stosowanie jakichkolwiek pojęć abstrakcyjnych nie znajduje uzasadnienia.
- implementacja w bazach danych dziedziczenia jest co najmniej "trudna".

Tworząc wymagania w postaci: Use case, model dziedziny i sekwencje dla use case daje bardzo jednoznaczny materiał architektowi systemu, ten ma na głowie stworzenie modelu implementacyjnego w tym realizacje wymagań pozafunkcjoalnych (ograniczeń systemu).

Uważam, że należy unikać sytuacji w których na etapie implementacji ktokolwiek musiał by się czegokolwiek domyślać.

P.S.
Dziedziczenie ma sens w klasach wykonawczych> W modelu dziedziny są to np. klasy zawierające sposoby postępowania, reguły biznesowe, algorytmy itp.. Np. faktura nie powinna być podklasą "dokument", powinna być agregatem swoich części (adres wystawcy, nabywcy, poszczególne pozycje, nagłówek itp.) za to sposób wytworzenia faktury powinien być metodą klasy np. "Fabryka faktur" która wie jak to robić (klasyczny wzorzec Fabryka abstrakcyjna wraz z ewentualnie wzorcem Prototyp). Faktura jako jedyna jest składowana w bazie danych klasa Fabryka to kawałek kodu łatwy do modyfikacji.

Temat: Analitycy biznesowi...

Tomasz Miodek:
1. Analizowanie i usprawnienie procesów organizacji
2. Zbieranie informacji od zamawiającego/przyszłego użytkownika oprogramowania i przekładanie tego na precyzyjne wymagania
3. Opracowanie precyzyjnych wymagań i powiązanie ich z konkretną technologią
4. Kodowanie (tworzenie kodu, programowanie)
5. Testowanie
6. Utrzymanie, administracja oprogramowaniem, poprawa wydajności i błędów

a gdzie projektowanie??????
a punktu 3. nie rozumiemJarek Żeliński edytował(a) ten post dnia 11.09.10 o godzinie 19:30