| Tytuł artykułu: |
Wprowadzenie. Etapy budowy systemów informatycznych. |
| Pierwszy wysłał: |
Sat 17 Nov 2007 |
| Opis: |
„Sytuacje i zagadnienia jakie pojawiają się podczas tworzenia złożonych systemów informatycznych są trudne, zwykle problematyczne i często pozostają nierozwiązane. Przestawiona poniżej historia etapów budowania systemów informatycznych, stanowi kontekst dla tego artykułu. Oznacza to również, że tematy poruszone w artykule, będą często wykraczały poza te, które są znane z dziedziny wiedzy modelowania systemów informatycznych”. |
|
Treć artykułu:
Streszczenie artykułu pt. Wprowadzenie - Etapy budowy systemów informatycznych.
„Sytuacje i zagadnienia jakie pojawiają się podczas tworzenia złożonych systemów informatycznych są trudne, zwykle problematyczne i często pozostają nierozwiązane. Przestawiona poniżej historia etapów budowania systemów informatycznych, stanowi kontekst dla tego artykułu. Oznacza to również, że tematy poruszone w artykule, będą często wykraczały poza te, które są znane z dziedziny wiedzy modelowania systemów informatycznych”.
Zapewne większość osób zaangażowanych w branżę projektów systemów informatycznych, poznało zabawną a może i tragiczną, historyjkę o etapach budowania systemów informatycznych. Przedstawione tam rysunki, tytułują obszary prac - które niewątpliwe dotyczą każdego projektu systemu informatycznego na świecie. Tragizm tej opowieści, wynika z błędów popełnianych przez osoby uczestniczące w takich etapach projektu jak: „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ł”.
Wysoce prawdopodobne jest, że interpretacji tychże rysunków jest tyle, ilu jej czytelników. Pozwolę sobie na uproszczenie i zgrupowanie tych odbiorców na: praktykujących i studentów. Jednak muszę tu zaznaczyć, że w tej dziedzinie wiedzy stosunkowo trudno wyznaczyć granice pomiędzy przedstawicielami tychże grup. Wynika to z faktu, że w branży projektów informatycznych, gdzie nieustannie ewoluują techniki ich wytwarzania trudno sprostać nowym wyzwaniom - bez ciągłej nauki (a więc studiowania). Tym samym można byłoby stwierdzić, że interpretacji tej zabawnej historyjki dokonują zawsze studenci! Takie stwierdzenie, nadaje sens istnienia faktu różnej interpretacji tychże rysunków, jako że: każdy z jej odbiorców jest studentem i cechuje się inną wiedzą i doświadczeniami. Uznajmy wobec tego, że właściwszym podziałem będą: zdefiniowani powyżej studenci oraz pozostali, którzy pragną pozostać przy nabytej wcześniej wiedzy. W niniejszym artykule, będę się odnosił do osób, które rozwijają się - są studentami. Takie podejście, pozwoli również rozróżnić firmy specjalizujące się w projektowaniu rozwiązań dedykowanych od firm produkujących jeden produkt, często dla jednego klienta. Rozróżnienie takie, pozwala również przybliżyć problematykę firm o nieskrępowanym potencjale rozwoju. Użyte pojęcie „nie skrępowania” oznacza tu - możliwość rozwoju, elastyczność i zdolności adaptacyjne.
Przedstawione rysunki, w stosunkowo prosty sposób ukazują poszczególne etapy budowy systemu informatycznego. Jak wiadomo od wielu lat, model kaskadowy wytwarzania systemów informatycznych, jest nieefektywny. O wiele bardziej sprawdzony jest model iteracyjno-przyrostowy. Przyczynia się to do spostrzeżenia, że przedstawioną historię, należy interpretować w obecnych czasach w bardziej dynamicznym kontekście(iteracyjno-przyrostowym) niż tym, który wynika bezpośrednio z rysunku (kaskadowym).
Na wiele sposobów, przedstawia się metody budowania systemów informatycznych. Często są to książki, artykuły, konferencje i szkolenia. Należy tu zauważyć, że dotyczą one tylko niektórych opisywanych etapów: „To, czego klient potrzebował”, „To, co wykonali programiści”, „To, co opisywał projekt”, „To, co analityk zrozumiał ”. Pozostałe już mniej formalne, pozostają bliżej nie sprecyzowane i nie spotyka się np. szkoleń, tj. „To, co klient zamówił”, „Po uruchomieniu i wdrożeniu”, „To, za co klient zapłacił”.
Należy tu zauważyć pewną zależność i przyczynę takiego stanu rzeczy. Metody budowania systemów informatycznych, są opisywane i przedstawiane w środowisku „laboratoryjnym”. Oznacza to również, że tylko z pomiędzy wierszy można wyczytać jak osadzić, zaadoptować i wykorzystać przedstawiane metody i techniki w praktyce. Skutkiem takiego stanu rzeczy, nie jest tylko nie sprecyzowanie poszczególnych etapów budowania systemów informatycznych ale przede wszystkim: oddziaływania tychże etapów na te mocno wspierane przez metody, notacje i narzędzia projektowe.
Zależności pomiędzy etapami budowania systemów informatycznych są oczywiste. Wobec tego, trudne i skazane z góry na niepowodzenie jest rozpatrywanie z osobna poszczególnych etapów budowania systemów informatycznych. Dlatego też, każdy z etapów będzie opisany z uwzględnieniem otoczenia, w którym się znajduje.
Pierwsza grupa etapów budowania systemów informatycznych („To, czego klient potrzebował”, „To, co wykonali programiści”, „To, co opisywał projekt”, „To, co analityk zrozumiał ”) jest rozpatrywana i mocno otoczona „interesantami”. Wyróżnia się tu głównie osoby z branży, tj. naukowców, inżynierów i innych wybranych uczestników projektów. Praktycznie nie dziwi już nikogo wykorzystanie technik modelowania obiektowego, notacji UML i narzędzi CASE. Jednak dopiero praktyka pokazuje, jakie trudności w wielu organizacjach wiążą się z wdrożeniem tychże rzeczy. W jednym zdaniu można byłoby scharakteryzować te trudności poprzez użycie sformułowań: mentalność ludzka, motywacja, niejasny cel zmiany kultury pracy, niejasny zakres wykorzystania technik modelowania obiektowego, pieniądze.
Druga grupa etapów budowania systemów informatycznych („To, co klient zamówił”, „Po uruchomieniu i wdrożeniu”, „To, za co klient zapłacił”), jest bliższa menadżerom a zarazem dalsza inżynierom. Przyczynia się to najczęściej do istnienia dwóch zależnych ale bardzo oddalonych od siebie obszarów projektu, tj. obszaru prac związanych z budową systemu informatycznego - w tym zarządzania produktem oraz obszaru prac związanych z handlem, marketingiem i zarządzaniem projektem. Można tym samym wywnioskować, że zarządzanie projektem oraz produktem, występują w odrębnych otoczeniach. Powiązanie, zależność i powodzenie komunikacji tych dwóch obszarów, jest zależne zwykle od jednostek w projekcie, często kierownika projektu.
Podsumowując, przedstawiona historia budowy systemów informatycznych, obrazuje niezrozumienie. Niewątpliwie, na to niezrozumienie mają wpływ: cechy uczestników projektu, ewolucja technik wytwarzania, odrębne obszary projektu, efektywna komunikacja. Doskonalenie procesu wytwórczego, bez ścisłej komunikacji z pozostałymi aspektami projektu, nie gwarantuje osiągnięcie zamierzonych rezultatów. Zdefiniowani wcześniej studenci, postrzegają historię jako zabawny wizerunek trudności, jakie spotyka się w projektach. Zdefiniowane wcześniej - osoby pozostałe, nie przejmują się zobrazowanymi problemami, z powodu doprecyzowanych czynności, które wykonują codziennie.
Zapraszam do kolejnych publikacji z serii „Etapy budowania systemów informatycznych”.
Artykuły powiązane:
1. "To, co klient zamówił z serii Etapy budowy systemów informatycznych" Link: http://www.uml.com.pl/modules/articles/article.php?id=31"
2. "To, co analityk zrozumiał. Etapy budowy systemów informatycznych"
http://www.uml.com.pl/modules/articles/article.php?id=32
3. "To, co opisywał projekt. Etapy budowy systemów informatycznych" Link:
http://www.uml.com.pl/modules/articles/article.php?id=60 |
|
|