| To, co opisywał projekt. Etapy budowy systemów informatycznych. |
|---|
| Napisane przez Fri 08 Aug 2008 przez Artur (6405 cztane) |
|
„To, co opisywał projekt” Streszczenie "To co opisywał projekt" jest szczególnym artykułem na stronie internetowej poświęconej notacji UML. Dyskutujemy tu o różnych sytuacjach i technikach modelowania. Artykuł ten, siłą rzeczy musiał wykroczyć poza naukę określoną przez autorów zza oceanu. Musiał uwzględnić to środowisko w jakim projekty systemów informatycznych powstają. Prawde powiedziawszy, tytuł tego artykułu mógłby w pewnym kręgu interesantów zastąpić wszystkie opisywane etapy zabawnej historii „To, co klient zamówił”, „To, co analityk zrozumiał”, „To, co opisywał projekt”, „To, co wykonali programiści”, „Po wdrożeniu i uruchomieniu”, „To, za co klient zapłacił”, „To czego klient potrzebował”. Z jednej strony, zinterpretowaliby w ten sposób tytuł „To, co opisywał projekt” studenci natomiast z drugiej zaawansowani specjaliści. Dlaczego ? Otóż, studentom często może wydawać się, że to proste, aby projekt opisywał (spójnie) wszystkie te etapy, natomiast „zaawansowanym specjalistom”, że wykorzystując pewne techniki i ogromne doświadczenie oraz postępując w zgodzie z osiągnięciami inżynierii oprogramowania - po wielkich trudach ale jednak jest to możliwe! Cóż, przykrą prawdą jest, że ani studenci ani zaawansowani specjaliści nie uczestniczą w trwających projektach systemów informatycznych. Tacy studenci nie kwalifikują się, aby w nich uczestniczyć, natomiast nieliczni specjaliści wiedzą, że ideały i założenia teoretyczne giną wśród rzeczywistości i najczęściej obserwują zagadnienia z boku. Jednak naprowadzając artykuł na właściwsze inżynierom oprogramowania tory, przyjrzyjmy się wobec tego - „co opisywał ten projekt ?” „To, co klient zamówił” - artykuł o tym tytule, naprowadził nas na pewien tok myślenia. Pisało tam, że trudno wymagać od klienta, aby wyspecyfikował takie wymagania - które będą zadawalające i jednoznacznie zrozumiałe dla inżynierów. Jednak to co już pochodzi od klienta w jakkolwiek formie zapisane, jednak określa te wymagania. Proawdopodobne jest, że jeżeli zastosowany tu UML a więc przypadki użycia i ich specyfikacja została zrobiona właściwie - to świat staje się prostszy a wymagania klienta właściwsze i uzasadnione. Jednak, przywołując osoby pozostałe od studentów i specjalistów, słowo „właściwsze” budzi wiele wątpliwości. Chciałbym zwrócić szczególną uwagę właśnie na przypadki użycia - bo jak wiadomo to one stanowią kręgosłup projektu. Podstawy technik obiektowych mówią nam, że takie perspektywy jak: projektowa, implementacyjna, procesowa oraz wdrożeniowa są rozpatrywane przez pryzmat „Perspektywy przypadków użycia”. A więc, niech Ci co bagatelizują przypadki użycia do określeń znanych jako „bąble”, „jajka” - na chwilę zapomną o sobie i spojrzą na przypadki użycia jak na owoc wielu, wielu lat doświadczeń oraz mnóstwie prac naukowych na ten temat. Wracając, do tych moich wątpliwości dotyczących właściwego interpretowania przypadków użycia, można byłoby przywołać fakt pomijania bogatej literatury na ich temat oraz stwierdzić: nie przywiązuje się takiej uwagi do przypadków użycia jakie ma ona znaczenie według twórców UML'a. I proponuję pozostawić w spokoju kolejne, stosunkowo łatwiejsze etapy pracy w procesie wytwórczym opartym o notację UML dopóty, dopóki autor przypadków użycia tworząc je weźmie pod uwagę cel ich stosowania: - a więc zrozumienie oczekiwań klienta przez wykonawcę projektu (wykonawca to nie tylko analityk ale również kierownik projektu, projektant, programista, tester, architekt i inni mniej popularni ale jednak: inżynier procesu wytwórczego, dokumetalista, pozostali udziałowcy), - odniesienie się do pewnego miejsca w procesie biznesowym (przyjmijmy definicję procesu biznesowego stosowaną w metodyce RUP), - łatwość zarządzania wymaganiami funkcjonalnymi w całym procesie wytwórczym (w tym tworzenia bardzo istotnych przypadków testowych). A więc, co opisywał projekt ? Z jednej strony musielibyśmy odrzucić problemy natury niewiedzy o tych stosunkowo nowych technikach obiektowych i otoczeniu z nimi związnymi. I skupić się na tym aspekcie, kiedy kompetentny i doświadczony zespół projektowy opisuje projekt. I odpowiedź na pytanie “To, co opisywał projekt” jest banalnie prosta. Projekt opisywał to, co było potrzebne całemu zespołowi, któremu zależy na tym - aby skończyć projekt z sukcesem. Jednak muszę tu podkreślić, że cały zespół to nie tylko te osoby które zidentyfikowałem w artykule “Wprowadzenie. Etapy budowy systemów Informatycznych” (http://www.uml.com.pl/modules/articles/article.php?id=30), jako skupione wokół produktu ale również te, które skupione są wokół projektu. A więc byty, które w takim projekcie są zamieszczone, spełniają oczekiwania wszystkich uczestników “projektu informacyjnego i informatycznego”, którym zależy na odniesieniu sukcesu w zakresie własnego obszaru pracy. Proces wytwórczy m.in RUP i jego elastyczne dostosowanie do całego zespołu projektowego, pozwala nam zapanować nad złożonością, często uzasadnionej wywiórczej organizacji projektu. Metodyczne podejście, pozwala nam zapanować również nad brakiem spójności występującej pomiędzy potrzebami różnych uczestników projektu. Podsumowując artykuł pt. “To, co opisywał projekt” zastanówmy się nad podstawami organizacyjnymi całego projektu zanim zaczniemy tworzyć tzw. “dokumentację”. Tym, którzy myślą o tytule “To co opisywał projekt” w kategoriach pospolitego znaczenia słowa “dokumentacja” uzmysłówmy, że w tych złożonych projektach, gdzie faktycznie jest potrzebny opis projektu - dokumentacja jest jedynie miłym zakończeniem projektu i niczym więcej. Projekt powstaje na wszystkich etapach i jest rozbudowywany w każdej z iteracji. Dokumentacja w dzisiejszych czasach, powstaje automatycznie na bazie opisu projektu. Wszystkim przeciwnościom takiego stanu rzeczy, należy rozsądnie uzmysłowić o konsekwencjach takich przeciwności. Zapraszam do dyskusji! Artykuły powiązane: 1. "Wprowadzenie z serii Etapy budowy systemów informatycznych" Link : http://www.uml.com.pl/modules/articles/article.php?id=30 2. "To, co klient zamówił z serii Etapy budowy systemów informatycznych" Link: http://www.uml.com.pl/modules/articles/article.php?id=31" 3. "To, co analityk zrozumiał. Etapy budowy systemów informatycznych" http://www.uml.com.pl/modules/articles/article.php?id=32 |
| Indeks :: Drukuj :: E-mail |
Komentarze są własnością ich autorów. Nie ponosimy odpowiedzialności za ich treść.
