STRONA GŁÓWNA FORUM ARTYKUŁY
   Logowanie | Rejestracja
Menu główne
Przegląd UML 2.0

Diagramy UML 2.0 -więcej...
Diagram klas - więcej...
Diagram przypadków użycia -więcej...
Diagram obiektów - więcej...
Diagramy pakietów - więcej...
Diagram czynności -więcej...
Diagram maszyn stanowych -więcej...
Diagramy modelowania analitycznego -więcej...
Diagramy struktur połączonych -więcej...
Diagramy sekwencji -więcej...
Diagramy komunikacji -więcej...
Diagramy harmonogramowania-więcej...
Diagramy komponentów-więcej...
Diagramy sterowania interakcją -więcej...
Diagramy rozlokowania -więcej...
Wkrótce powstaną kolejne opracowania

Modelowanie UML na stronie WWW

Poniższy link prowadzi do strony www, gdzie można modelować w języku UML na stronie internetowej! Darmowe narzędzie!
http://gliffy.com/gliffy/

Oferty pracy


Projektowanie Systemów Informatycznych w praktyce.
  Napisane przez Fri 19 Aug 2011 przez Artur (2772 cztane)
Autor: Artur Machura
artur.machura (at) uml.com.pl
tel. 501-176-256

Projektowanie Systemów Informatycznych
Zagadnienie „projektowania” pojawia się praktycznie w każdym przedsięwzięciu informatycznym. Można realizować prace projektowe, niemal na każdym etapie przedsięwzięcia. A więc nie tylko podczas etapu samego projektowania systemu informatycznego ale również i podczas analizy biznesowej, analizy systemowej, programowania, testowania. Zasadniczą różnicą pomiędzy tymi pracami jest wynik końcowy. Mówi się o tzw. modelach koncepcyjnych, logicznych, fizycznych a czasami o tzw. różnych poziomach abstrakcji.
Kolejne strony rozdziału poświęconego „Projektowaniu Systemów Informatycznych” - mają na celu wprowadzić czytelnika do świata pojęć i zagadnień, które każdy projektant systemów informatycznych powinien znać. A więc, nie skupiono się tu na opisie pewnych technik projektowych. Natomiast opisano środowisko pracy projektanta. Wiedza ta, nie tylko samemu projektantowi pozwoli wykonywać prace projektowe w sposób obiektywny ale co bardzo istotne - poznać pozostałym członkom zespołu specyfikę tej pracy (m.in. Analitykom, Programistom, Kierownikom, Testerom). Co stanowi bardzo istotny czynnik, który wpływa na poprawność modeli. Dlaczego? Otóż, to właśnie projektant systemów informatycznych powinien podejmować obiektywne i właściwe decyzje. Oparte często o potrzeby biznesowe - definiowane najczęściej przez analityków. W innym przypadku, wcześniej czy później projekt czeka problem, nawet klęska. Koszty błędów popełnionych na etapie projektowania zalicza się do tych największych. W oparciu o te prace implementuje się rozwiązanie, co niejednokrotnie angażuje wielo - osobowy zespół wytwórczy i pochłania znaczne koszty.

W rezultacie zapoznania się z artykułem, dowiesz się:
 Jakie czynniki przedsięwzięć IT mogą wpływać na pracę projektanta.
 Że praca projektanta systemów informatycznych związana jest ze znacznie szerszym spektrum zagadnień aniżeli tylko „specyfikowaniem” (np. z wykorzystaniem notacji UML).
 O tym, że poprawność produktów wytwarzanych przez projektantów wynika i jest zależna od tych z poprzedniego etapu cyklu wytwórczego - Analizy.

Czytając artykuł, powinieneś mieć na uwadze:
 Efekty pracy analityków czy też programistów zasadniczo wpływają na pracę i specyfikacje wytwarzane przez projektanta.
 Wybrany proces wytwórczy w istotny sposób wpływa na oczekiwania wobec pracy projektanta.
 O poprawności produktów projektowych nie świadczy tylko znajomość aspektów technologicznych ale również i organizacyjnych przedsięwzięć IT.

Rola projektanta w przedsięwzięciach informatycznych

Stanowisko projektanta systemów informatycznych w ostatnim czasie, znajduje coraz większe zainteresowanie w projektach IT. Wiąże się to zasadniczo z coraz to bardziej zaawansowanymi systemami, które wymagają wiedzy specjalistycznej od wszystkich uczestników przedsięwzięć IT, w tym projektantów. A więc kim jest projektant systemów informatycznych ? Niewątpliwie, odpowiadając rzeczowo na to pytanie, należy spojrzeć z perspektywy otoczenia pracy którą wykonuje. Bowiem praktyczne wykorzystanie Inżynierii Oprogramowania, wymaga znacznie szerszego spojrzenia niż tylko podstaw teoretycznych. Poza wiedzą dotyczącą bezpośrednio informatyki, na efekty pracy mają wpływ:
 cel przedsięwzięcia informatycznego,
 złożoność projektu,
 proces produkcji oprogramowania,
 kompetencje pozostałych uczestników projektu.

Można byłoby tym samym zauważyć, że projektant jest zależny od środowiska pracy, a więc specyfiki firmy w której wykonuje obowiązki oraz samego klienta - odbiorcy projektu. Jego praca nie polega tylko na stosowaniu zaawansowanych narzędzi wspierających projektowanie - CASE (Computer Aide Software Engineering). Ale przede wszystkim, znajomości samego celu samego przedsięwzięcia i umiejętności pogodzenia wielu problemów projektowych z celem przedsięwzięcia. Dlaczego? Otóż nawet najlepszy projekt - dostarczony po czasie, czy też którego prezentacja jest niezrozumiała, może nie przynieść pożądanej wartości przedsięwzięciu. Wynikiem takiego stanu rzeczy, jest częsta spotykana sytuacja - gdzie projektantem zostaje doświadczony pracownik firmy, często wykonujący prace również implementacyjne.
Złożoność projektu, w drastyczny wręcz sposób może zmieniać koncepcję projektowania. Bowiem, w takich projektach nie wystarczy już być ekspertem technologicznym, ale również cechować się: zdolnościami organizacyjnymi, komunikatywnością i zdolnością do wykonywania pracy w zespole, umiejętności wykorzystania narzędzi CASE w taki sposób, aby zapewnić aktualność oraz czytelność projektu również wtedy, kiedy projekt ewoluuje i zmienia się.
Projektant systemów informatycznych, nie może pozostawać obojętny względem harmonogramu i procesu produkcji oprogramowania. Przekrój modeli wytwórczych, opisywanych przez wiele książek Inżynierii Oprogramowania, w istotny sposób wpływa na postrzeganie produktów pracy Projektanta. Zupełnie innych rezultatów oczekuje się od projektanta biorąc choćby pod uwagę dwa skrajne modele: kaskadowego czy też iteracyjno - przyrostowego.
Rozważając rolę projektanta w przedsięwzięciach, trudno nie uwzględniać również i pozostałych członków zespołu. Jako, że projektant dostarcza produkty - które z jednej strony powiązane są z analizą a drugiej z samą implementacją - niewątpliwie inne mogą być oczekiwania od projektu, w zależności od sposobu pracy i efektów analizy oraz implementacji. Projekt ten, wiąże ze sobą - można powiedzieć zupełnie odmienne światy: rzeczywistości (produkty analityczne) oraz informatyki (produkty implementacyjne). Oznacza to, że z racji tej odpowiedzialności jaką projektant przyjmuje w zespole, powinien swoją pracą wypełnić niezbędne i potrzebne w przedsięwzięciu byty. Mowa tu o produktach projektowych i ich specyfikacji.

Podsumowując pokrótce rolę projektanta w przedsięwzięciach informatycznych:

 dostarcza projekty, które spełniają oczekiwania pozostałych członków zespołu,
 praca którą wykonuje, wiąże ze sobą etapy cyklu wytwórczego: analizę i implementację,
 buduje takie modele, które umożliwiają na implementację przemyślanych rozwiązań.

Przedsięwzięcia informatyczne a projektowanie
Przedsięwzięcia informatyczne nadają realne definicje wszelkim zagadnieniom, z którymi wiążemy projekt. Dlatego też, myśląc o projektowaniu, zwróćmy uwagę w pierwszej kolejności na fazy tych przedsięwzięć oraz zaangażowanie poszczególnych obszarów pracy w tych fazach. Gdzie też, poszczególne obszary pracy nieustannie oddziałują na siebie. Dopiero takie spojrzenie, pozwoli praktycznie ująć wpływ przedsięwzięć informatycznych na dyscyplinę inżynierską „Projektowanie”. Poniższy rysunek prezentuje popularny proces wytwórczy RUP (Rational Unified Process), który stanowi pewien wymowny model zaangażowania poszczególnych dyscyplin Inżynierskich na kolejnych fazach przedsięwzięć informatycznych.



Rysunek 1 Proces wytwórczy RUP

Na powyższym rysunku, należy zwrócić szczególną uwagę na te elementy, które bezpośrednio rzutują na sposób jak i cel wykonywania prac projektowania. Gdzie na pewno należy wymienić:
 rozpoczęcie prac już podczas trwania prac analitycznych, mało tego - ścisłe kooperowanie i wzajemne oddziaływanie pomiędzy obszarami analizowania a projektowania,
 zapewnienie takiej organizacji pracy, wliczając również repozytorium projektowe - aby umożliwić na łatwe wprowadzanie zmian względem częstych zmian produktów analitycznych,
 stałe pozyskiwanie wymagań odbiorców projektu - programistów i uzgadnianie efektów pracy do ich zapotrzebowania.
Prezentowany model wytwórczy, jest jednym z wielu. W jednym z kolejnych punktów niniejszego artykułu pt. ”Proces wytwórczy a projektowanie” zostały wymienione i scharakteryzowane również i pozostałe procesy wytwarzania oprogramowania. Natomiast wybrany model z rodziny ewolucyjnych „iteracyjno - przyrostowy”, obrazuje istotną tu dynamikę oddziaływania poszczególnych obszarów na siebie. Środowisko wytwarzania systemów informatycznych na potrzeby spełniania dynamicznych potrzeb biznesowych, właśnie tak powinno być postrzegane. A więc:
 umiejętnie zarządzać zmianami w każdym z obszarów pracy,
 dążyć do efektywnej komunikacji w zespole, która jest kluczowa dla powodzenia w osiąganiu celów projektu.

Proces Wytwórczy Oprogramowania a Projektowanie
Proces wytwarzania oprogramowania, jak wspomniano wcześniej - zasadniczo oddziałuje na to jak i co projektujemy. Wpływa nie tylko na sposób wykonywania prac ale przede wszystkim ich wynik końcowy. A więc dlaczego tak się dzieje ? Specyfikacje modeli wytwórczych, często wymieniają zastosowanie następujących dyscyplin Inżynierii Oprogramowania:
 zarządzanie,
 analizowanie,
 projektowanie,
 programowanie,
 testowanie,
 konfigurowanie,
 wdrażanie.

Rolą procesów wytwórczych, uogólniając jest zarządzanie kolejnością i zakresem wykonywania prac w poszczególnych w/w krokach cyklu wytwarzania. Co w rezultacie pozwala na wytwarzanie systemów w sposób przewidywalny, gdzie zarządza się m.in. jakością tych systemów. Dążąc przy tym do spełnienia co najmniej wymagań odbiorców i przyszłych użytkowników tych systemów.
Ten krótki wstęp, miał na celu przybliżyć związek „Projektowania Systemów Informatycznych” - nie tylko z samą informatyką i wytwarzaniem systemu ale również:
 podejmowaniu decyzji projektowych ze świadomością ich wpływu na losy całego projektu,
 spełnianiu celów biznesowych, często wyrażanych przez wymagania przyszłych użytkowników,
 wywiązywaniu się zespołu wytwórczego, za pośrednictwem projektu systemu, z wymagań określanych często na etapie analizowania,
 związkiem decyzji projektowych z jakością systemów i wywiązywaniu się zespołu z przyjętych w przedsięwzięciu kryteriów jakości.
 możliwością produkowania oprogramowania na czas, w zgodzie z harmonogramem,
 zapewnieniu takiej specyfikacji, która zapewni rozwój systemu nawet na etapie jego eksploatacji.

Projektowanie systemów informatycznych, jak można wywnioskować z powyższego, jest ściśle związane ze spełnianiem oczekiwań zamawiającego, organizacją projektu a więc procesem wytwarzania oprogramowania. Dlatego też, w kolejnych akapitach zostanie przybliżony wpływ wybranych procesów wytwarzania na projektowanie systemów informatycznych.

 Zwinne wytwarzanie oprogramowania
Zwinne wytwarzanie oprogramowanie, ma charakter ewolucyjny ale sama nazwa wywodzi się z perspektywy łatwo wprowadzanych zmian w implementacji. Prace projektowe postrzega się najczęściej jako towarzyszące implementacyjnym. Oznacza to, że podczas realizacji prac głównie nastawionym na szybkie osiąganie efektów w postaci oprogramowania - wykonuje się prace projektowe. Z czego można wywnioskować następujące skutki:
o prace projektowe często wykonują osoby, które również programują,
o projekt zwykle obrazuje tylko pewne fragmenty potrzebne zespołowi w celu zrozumienia danego problemu i poprawnej implementacji,
o zwykle nie powstaje produkt „Projekt”, jedynie szczątkowe modele,
o częste kontakty z klientem mają na celu prezentowanie oprogramowania, co również rzutuje na małe zainteresowanie dokumentacją w czasie trwania projektu,
o dokumentacja i specyfikacja powstaje zwykle na końcu projektu, głównie na potrzeby odbioru produktu.

 Ewolucyjne wytwarzanie oprogramowania
Ewolucyjne wytwarzanie oprogramowania, obejmuje grupę modeli wytwórczych, gdzie z góry zakłada się rozwój przedsięwzięcia poprzez wprowadzanie zmian praktycznie na wszystkich etapach cyklu wytwórczego - w tym projektowania. Jak powszechnie wiadomo, takie podejście niesie ze sobą wiele korzyści dla przedsięwzięć informatycznych ze względu na elastyczność, ale wymaga dużej sprawności zespołu we wprowadzaniu tych zmian w projekcie. Dlatego też, należy wymienić co najmniej następujące cechy prac związanych bezpośrednio z projektowaniem systemów informatycznych:
o ze względu na możliwość jednoczesnego uczestnictwa większej liczby osób w pracach analityczno - projektowych) - organizacja repozytorium projektowego powinna umożliwić na bezkolizyjną pracę,
o repozytorium projektowe powinno zapewnić wersjonowanie i możliwość wyświetlania modeli projektowych przed i po wprowadzeniu zmian,
o modele analityczne, na podstawie których będą wprowadzane zmiany w projektach - powinny w przejrzysty sposób umożliwić na odczytywanie wpływu tych zmian na dalsze prace projektowe,
o skutki wprowadzania zmian w modelach projektowych, powinny informować w przejrzysty sposób o ich wpływie na samo kodowanie, dlatego też w najlepszym przypadku oczekiwałoby się na takie wykorzystanie środowisk projektowo - developerskich aby kod wynikowy był zintegrowany z projektem,
o specyfikacja projektowa jest nastawiona na ciągłe zmiany i rozwój - co oznacza, że powinna zapewnić odpowiednio dokładny poziom dokładności do wprowadzania zmian i dalszego rozwoju.

 Sekwencyjne wytwarzanie oprogramowania
Praktyczne wykorzystanie sekwencyjnego podejścia do wytwarzania oprogramowania - wiąże się z najwyższym poziomem dokładności. Odgórne założenie, do tylko jednokrotnego wykonywania poszczególnych prac na poszczególnych etapach cyklu wytwórczego - nie tylko podnosi poziom dokładności ale również odpowiedzialność za poszczególne decyzje, w tym projektowe. Generalnie rzecz ujmując - z chwilą przekazania projektu do implementacji, nie powinniśmy wprowadzać już żadnych zmian w tym projekcie! Z czego można wywnioskować następujące cechy oddziałujące bezpośrednio na projekt:
o projekt, który nie cechuje się wprowadzaniem zmian - powinien być bardzo dokładnie rozpatrywany na poszczególnych etapach cyklu wytwórczego,
o z chwilą rozpoczynania prac projektowych, należałoby zweryfikować dokładność i jakość prac wcześniejszych - analitycznych,
o wykorzystanie poszczególnych technik wspierających prace projektowe, powinno cechować się wysoką szczegółowością - która ma na celu zmniejszyć ryzyko niepoprawnego zrozumienia w dalszej pracy dotyczącej kodowania.


Wyżej scharakteryzowane popularne a zarazem skrajnie różne modele procesów wytwórczych, wymagają zupełnie innego podejścia do prac dotyczących projektowania systemów informatycznych. Co również oznacza, że przed samym rozpoczęciem tej pracy, należałoby sobie zadać kilka pytań - wśród których na pewno powinny się znaleźć:

 Jakie są oczekiwania wobec jakości systemu ?
 Jaki jest termin wykonania prac ?
 W jaki sposób będzie pracować zespół wytwórczy ?
 Jakie kompetencje posiadają poszczególni użytkownicy a przynajmniej jaką odpowiedzialność za prace mają poszczególni członkowie zespołu ?
 Czy repozytorium projektowe zostało skonfigurowane i dostosowane do potrzeb organizacyjnych projektu ?
 Czy została podjęta decyzja o stosowanej notacji pozwalającej obrazować produkty analityczne ?
 Czy zostało wybrane narzędzie CASE oraz czy zakres jego zastosowania został ustalony ?


Podsumowanie:
Podsumowując przesłanie niniejszego artykułu - projektowanie systemów informatycznych jest kluczowe dla powodzenia przedsięwzięć informatycznych. Ponadto, z jednej strony jest zależne od pewnych prac a z drugiej wpływa na inne. Daje to taką perspektywę postrzegania, gdzie nie wystarczy rozumieć samą technologię ale również wpływ takich zagadnień jak: cele przedsięwzięcia, wykorzystanie inżynierii oprogramowania, organizacji projektu. W rezultacie czego, poprawnie można dopasowywać produkty projektowe. Dostarczać je na czas i względem konkretnego zapotrzebowania.
Indeks :: Drukuj :: E-mail
Komentarze są własnością ich autorów. Nie ponosimy odpowiedzialności za ich treść.
Znajdź na stronie


Warto odwiedzić


Unified Modeling Language


Unified Modeling Language


Unified Modeling Language


Wyższa Szkoła Technologii Informatycznych w Katowicach


Szkolenia Inżynierii Oprogramowania


Management Systems Consulting


MrHelp - strony Internetowe które pracują na Twój sukces


Magazyn Programistów i Liderów IT
Statystyki