WSTĘPZESPÓŁ PRZEDE WSZYSTKIM Zespół – efektywny dzięki właściwemu do-                           potrzeb klientów wewnętrzn...
Jazz    Zespół przede wszystkim    Ułatwienia w komunikacji między zespołami, zwiększenie przewidy-    walności projektów,...
Jazznajlepszych praktyk z obszaru inżynierii opro-         kiej jakości. W związku z tym, skupiono się na          Raporto...
•  Zakłada się, że istnieje otwarty, elastyczny,        rozproszony model danych. Nie zakłada się         Odniesienia     ...
Zwinność i dyscyplina    w podnoszeniu efektywności    zespołów projektowych    W artykule przedstawiono założenia metodyk...
Zwinność i dyscyplinawytwarzanie dokumentacji projektu. We-                Czas trwania iteracji nie jest ściśle określony...
Zespół projektowy pracuje w określonym              gerować w prace zespołu. Nie powinno się           OpenUP     przedzia...
Zwinność i dyscyplinaproblemów. Ostatni tydzień lub kilka ostat-nich dni iteracji zazwyczaj poświęconych jestw dużej mierz...
aby nie popaść w zbyt szczegółowe testowanie                       Pierwszy z widoków architektonicznych sta-        mi Ko...
Zwinność i dyscyplinakich klas użytych w iteracji. Uzyskano procen-towy udział obydwu tych liczb w liczbie wszyst-        ...
Wywiad                               z Januszem Górskim                                                               rozm...
Wywiad z Januszem Górskimdo końca wiemy, jak powtarzać sukces w budo           Jakie wyzwania według Pana stają przed nowo...
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
SDJ Extra Zespół przede wszystkim
Upcoming SlideShare
Loading in …5
×

SDJ Extra Zespół przede wszystkim

3,850 views

Published on

Kompendium wiedzy o rozwiązaniach IBM Rational dla deweloperów, testerów i projektantów aplikacji

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,850
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

SDJ Extra Zespół przede wszystkim

  1. 1. WSTĘPZESPÓŁ PRZEDE WSZYSTKIM Zespół – efektywny dzięki właściwemu do- potrzeb klientów wewnętrznych czy zewnętrz- tury artykułów poświęconych platformie do borowi pracowników, kompetencji, wyzna- nych bez właściwych narzędzi informatycz- pracy grupowej IBM Rational Jazz, a także tak czonym rolom: obserwatora, kreatora, lidera, nych praca żadnego zespołu nie jest możliwa. ważnemu tematowi jak bezpieczeństwo analityka, itd. Na ile wszystkie te elementy Specjalny numer Software Developers’ Journal tworzonych aplikacji. Specjalnie dla Państwa mogą wystarczyć by zrealizować w wyznaczo- poświęcony jest właśnie narzędziom wspiera- prof. Janusz Górski w artykule poświęconym nym czasie stawiane przez organizację zadania, jącym pracę zespołów programistycznych, de- inżynierii oprogramowania zakreślił trendy osiągnąć cele? W dobie pędu za zaspokojaniem weloperskich, testerskich. Zachęcam do lek- i wyzwania, z którymi spotykają lub będą się spotykali Państwo w najbliższych latach. Za- chęcam również do lektury wywiadu z czter- Bartosz Chrabski nastokrotnym Mistrzem Europy w Rallycrossie IBM Rational Team Leader Jest starszym specjalistą IT pracującym w grupie oprogramowania IBM Polska. Zaj- – Kennethem Hansenem, poświęconego is- muje się projektowaniem i wdrażaniem systemów zarządzania pracą zespołów de- tocie pracy zespołu, bo przecież w dzisiejszych veloperskich oraz technicznym wsparciem sprzedaży rozwiązań do zarządzania czasach każdy sukces to praca zespołu, a nie i wytwarzania oprogramowania z rodziny IBM Rational. Specjalizuje się w techno- pojedynczego człowieka. Życzę udanej lektury logiach middleware oraz modelowaniu architektury SOA. Doktorant na wydziale i zachęcam do kontaktu z nami! Elektroniki i Technik Informacyjnych Politechniki Warszawskiej. Założyciel i lider Łódzkiej Grupy Użytkowników Technologii Java (Lodz JUG). SPIS TREścI Wytwarzanie oprogramowania Jazz – zespół przede wszystkim ......................................................... 4 z wykorzystaniem IBM Rational ........................................................ 32 Zwinność i dyscyplina w podnoszeniu IBM Rational Method Composer – portal procesowy ..................... 36 efektywności zespołów projektowych ............................................ 8 Komiks ........................................................................................................ 40 Z profesorem Januszem Górskim Zarządzanie procesami zapewnienia jakości rozmawia Bartosz Chrabski ................................................................ 14 z IBM Rational Quality Manager ...................................................... 42 O zwinnym tworzeniu oprogramowania ...................................... 16 IBM Rational AppScan Standard Edition ....................................... 46 Efektywna komunikacja Architektura korporacyjna w pigułce ............................................. 52 biznesu IT dzięki IBM Rational Requirements Composer .................................................................... 20 Rozmowa z Kennethem Hansenem ........................................................... 56 Adaptacja zwinnych metodyk Jazz i OSLC ................................................................................................ 58 z użyciem IBM Rational Team Concert ........................................... 26 Referencje ................................................................................................. 68Software Developer’s Journal Extra DTP: Marcin Ziółkowski, www.gdstudio.pljest wydawany przez Software-Wydawnictwo Sp. z o.o. Projekt okładki: Anna Adamczyk anna.adamczyk@software.com.plWydawca: Anna Adamczyk Nakład: 6 000 egz.anna.adamczyk@software.com.pl Dział reklamy: adv@software.com.plRedaktor naczelny: Łukasz Łopuszańskilukasz.lopuszanski@software.com.pl Adres korespondencyjny:Redaktor prowadzący: Tomasz Łopuszański Software Press Sp. z o.o., ul. Bokserska 1, 02-682 Warszawa, Polskatomasz.lopuszanski@software.com.pl tel. +48 22 427 36 91, fax +48 22 224 24 59Korekta: Tomasz Łopuszański www.sdjournal.org; cooperation@software.com.pltomasz.lopuszanski@software.com.plKoordynatorzy projektu: Bartosz Chrabski, Maciej Mroczek, Redakcja dokłada wszelkich starań, by publikowane w piśmie i na towarzyszą-Joanna Izdebska cych mu nośnikach informacje i programy były poprawne, jednakże nie bierzeKierownik produkcji: Andrzej Kuca odpowiedzialności za efekty wykorzystania ich; nie gwarantuje także popraw-andrzej.kuca@software.com.pl <<STRONA_PISMA>> nego działania programów shareware, freeware i public domain. 3
  2. 2. Jazz Zespół przede wszystkim Ułatwienia w komunikacji między zespołami, zwiększenie przewidy- walności projektów, integracja narzędzi, obniżenie ryzyka zawsze było wyzwaniem w projektach. Czy już jesteśmy gotowi, aby robić to efek- tywnie? Nie ma jasnej odpowiedzi na to pytanie, ale już wiemy, jak to zrobić z IBM Rational Jazz. W ytwarzanie  oprogramowania  to    •   wsparcie portfolio produktów, zględnia ona również zdefiniowane w OSLC    zawsze  złożony  i  rozbudowany   •   społeczność. –  Open  Services  for  Lifecycle  Collaboration   proces, który uważa się za sztu- specyfikacje, a także niezależne od dostawców   kę,  naukę,  rzemiosło,  wymagające  tajemnej  W przeciwieństwie do monolitycznych i za- zestawy protokołów współdzielenia informacji   wiedzy i lat doświadczenia. Często najbardziej  mkniętych produktów przeszłości, platforma  pomiędzy narzędziami.  niedocenianym obszarem we wszystkich re- Jazz jest otwarta i przeznaczona dla każdej oso-  alizowanych projektach IT jest ich wymiar spo-  by zainteresowanej, która chce poprawić cykl   Praca zespołowa łecznościowy, opisujący, jak ludzie pracują ze  życia oprogramowania i przełamać bariery mię-  Projekt Jazz składa się ze wspólnej platformy  sobą przy realizacji wspólnych oraz osobistych   dzy narzędziami. Produkty Jazz są uosobieniem  i zestawu narzędzi, które umożliwiają wszyst- celów. Duże przedsięwzięcie jest zależne nie od  innowacyjnego podejścia bazującego na otwar- kim członkom zespołu rozwojowego łatwiej- jednej, a wielu współpracujących i komuniku- tych, elastycznych usługach internetowych, a tak-  szą współpracę. Odzwierciedla to pogląd, że  jących się ze sobą osób, w określonym oczywiś-  że  najlepszych  praktykach  zgodnych  ze  stan-  najważniejszym elementem w rozwoju opro- cie porządku – wszystko po to, by końcowy pro-  dardami Opeb Web i OSGi Alliance.  gramowania nie są jednostki, nie proces, ale  dukt był jak najwyższej jakości. Zespołowe opra-  Platforma Jazz została zaprojektowana tak, by   współpraca  zespołu.  W  tym  celu  platforma  cowywanie  oprogramowania przypomina grę  dostarczać  organizacjom  elastyczność  umoż- udostępnia rozszerzalną architekturę zapro- w  zespole  muzycznym.  W  obu  przypadkach  liwiającą  przygotowanie  własnego,  idealnego   jektowaną  z  myślą  o  zwiększeniu  poziomu  niezbędna jest równowaga między umiejętnoś-  środowiska dostarczania oprogramowania, uży- współpracy, produktywności i przejrzystości  ciami indywidualnymi i współpracą w zespole. wając preferowanych narzędzi. Co więcej, poz-  produkcji oprogramowania.  Aby  ułatwić  zarządzanie  całym  procesem,   wala  elastycznie rozwijać  środowiska organiza-  Została  ona  dostosowana  do  potrzeb  ze- IBM stworzył platformę integracyjną nazwaną  cji wedle własnych wymagań, własnym tempem,   społów pracujących w zróżnicowanych lokali- Jazz. Dzięki odpowiedniemu podejściu do za- zamiast stać na drodze integracji narzędzi. Plat- zacjach, uzupełniając tą wiedzę dodatkowo o in- gadnienia, praca zespołu może być efektywna  forma definiuje wspólny zbiór usług Jazz Foun-  formacje dotyczące użytkowników, projektów   na różnych etapach cyklu wytwórczego opro- dation, które można wykorzystać w dowolnym   i procesów z elementami automatyzacji. Odpo- gramowania. Nazwa nawiązuje do faktu, iż mu-  narzędziu implementującym to podejście. Uw-  wiednie podejście do współpracy i zastosowanie  zycy zmieniają swoje uczucia w muzykę, nato  miast w przypadku branży IT chodzi o zmianę   sztuki dostarczania oprogramowania w będącą   bardziej transparentną i produktywną. Wizja Platforma Jazz jest inicjatywą firmy IBM, któ- ra powstała, aby pomóc zespołom w celu osią- gnięcia jak najlepszych wyników w pracy Au- torzy,wykorzystując dobre praktyki współpra- cy z obszaru muzyki, przekształcili je tak, aby  były możliwe do zastosowania w procesie wy- twarzania  oprogramowania,  czyniąc  je  bar- dziej spójne, wydajne i przejrzyste. Na fundamenty platformy Jazz wpływają  trzy elementy : •  architektura  integracji  dla  cyklu  życia  produktu, Rysunek 1. Strona WWW projektu IBM Rational Jazz4
  3. 3. Jazznajlepszych praktyk z obszaru inżynierii opro-  kiej jakości. W związku z tym, skupiono się na   Raportowaniegramowania pozwoliło na skrócenie cyklu po- fundamentach współpracy w zespole, automa- Uzyskanie szybkiego dostępu do informacji opar- wstawania  oprogramowania,  podniesienie   tyzacji procesów i raportowania cyklu życia opro- tych na faktach jest niezbędne do planowania dal- jakości oraz usprawniło samo zarządzanie pro- gramowania. Narzędzia Jazz odzwierciedlają za- szej pracy. Zbyt często raporty na temat stanu roz- jektem. łożenia, że najważniejszym obiektem nie jest tu   wijanego oprogramowania wiążą się ze żmudną   Na razie platformy Jazz zostały stworzone  jednostka czy proces, a współpraca. Zauważa się   pracą wymagającą wysiłku ludzi odpowiedzial-trzy produkty : również,  że  zespół  to  nie  tylko  grupa  progra-  nych za sprawozdania, co wymaga czasu, a to   mistów wraz z ich menedżerami, ale także po-  powoduje, że raporty są mniej aktualne. Jazz   zostali, którym zależy na sukcesie inicjatywy, czyli  koncentruje  się  na  dostarczaniu  raportów  •  Rational Requirements Composer  –  roz- klienci, sponsorzy. Celem narzędzi jest więc   w czasie rzeczywistym, które umożliwią wgląd   wiązanie  dedykowane  do  poprawnego  umożliwienie przejrzystości zespołów i projektów  w programy, projekty i użyteczność zasobów,   definiowania  wymagań  przy  zastosowa- dla  ciągłej  współpracy,  która  pozwala  na  pro-  co znacząco pomaga zespołom projektowym.   niu tekstu oraz rozbudowanych elemen- mowanie  przełomowych  innowacji,  budowę    Identyfikuje i rozwiązuje problemy znacznie    tów graficznych. Narzędzie umożliwia za- spójności zespołu, wykorzystanie zasobów, talen- wcześniej w cyklu życia oprogramowania, za-  pisywanie  wyrafinowanych  potrzeb  biz- tó w i  poza przedsiębiorstwem. miast szacowanych wartości, przedstawia met-  nesowych w jednoznaczne wymagania, co  ryki  bazujące  na  faktach,  co  zwiększa  efek-  na dalszych etapach prac nad produktem  Automatyzacja tywność podejmowanych decyzji, a także poz-  wpływa  bezpośrednio  na  poprawę  jako- Badania pokazują, że prawie wszystkie orga- wala  na  odpowiednie  wykorzystanie  metryk   ści czy usprawnienia samego procesu wy- nizacje chcą zmniejszyć liczbę biurokratycz- do poprawy prac zespołu. twórczego. nych przeszkód stojących na drodze rozwoju   •   Rational Team Concert – wspólne środowi- oprogramowania, automatyzując żmudne i po-  Architektura i implementacja Jazz sko pracy dla programistów, projektantów,  datne na błędy zadania oraz uciążliwe do utrzy-  Architektura Jazz oparta jest na zasadach będą-  architektów i kierowników projektów. De- mania  operacje  na  danych.  Jednak  oni  rów- cych kluczem do porzucenia podejścia stosowa-  dykowane  narzędzie  pozwalające  w  jed- nież muszą utrzymać i poprawiać proces spój-  nego w przeszłości. Wszystkie te zasady pozwa- nym miejscu na zarządzanie pracą, kontro- ności i zarządzania oraz zwiększać wgląd w rze-  lają zespołom na korzystanie z sieci WWW, by   lę źródeł, zarządzanie systemem budowa- czywisty postęp projektu. Celem Jazz jest au- uzyskiwać dostęp do procesów czy artefaktów   nia,  wsparcie  dla  planowania  iteracji  oraz  tomatyzacja procesów przepływów pracy i za- w ramach całego procesu wytwórczego. proces planowania, obejmuje zwinne me- dań, dzięki czemu organizacje mogą przyjąć  Oto kilka przykładowych idei: todyki, m.in. Scrum oraz Eclipse Way. odpowiednią liczbę zasad rozwoju w tempie, •   Rational Quality Manager – oparty o in-  które  ma  dla  nich  sens.  Otrzymujemy  więc   •  Oddziela się wdrażanie narzędzi od definicji   terfejs  www  system  zarządzania  proce- poprawę wsparcia i wykonywania procesów,  i dostępu do danych; semantyka danych nie   sem testowania dla decydentów oraz spe- włączając w to procesy zwinne (Agile) oraz sfor-  opiera się na sekretnej wiedzy wbudowanej   cjalistów ds. jakości. Dostarcza konfiguro- malizowane (Rational Unified Process), reduk-  w kod produktu. walne rozwiązanie do planowania testów,  cję żmudnych i czasochłonnych czynności ma-  •  Jazz może mieć dostęp i integrować dane tam,  przepływu kontroli, monitorowania i ra- nualnych, przechwytywanie informacji o postę-  gdzie się one znajdują – nie ma potrzeby im- portowania, realizacji testów czy zarządza- pach,  wydarzeniach,  decyzjach  i  zezwoleniach   portowania i eksportowania danych pomię- nia środowiskami testowymi. bez dodatkowego wprowadzania danych. dzy narzędziami i repozytoriami.Jazz to nie tylko społeczność praktyków roz-wijających  oprogramowanie,  którzy  poma-gają innym, to także wpływ klientów i spo-łeczności  na  kierunek  rozwoju  produktów przez wczesne, ciągłe i bezpośrednie rozmo-wy lub wymiany poglądów. Po  dołączeniu  do  społeczności  na  stronie jazz.net, można komunikować się z zespołami  projektowymi, śledzić postęp budowy produk- tów,  kamienie  milowe,  przekazać  informa-cje o tym, co działa, a co nie oraz zgłaszać i śle-dzić defekty.  Każda z osób ma pełną przejrzystość szczegó-łowych planów, stanu, postępu budowy samej platformy lub komercyjnych produktów IBM Rational.  Korzyść, jaka płynie z tej przejrzysto-ści i dostępności do danych, to przede wszyst-kim fakt, iż istnieje możliwość stania się jednym z decydentów wpływających na ich rozwój. Czę-ste dostarczanie trafnych opinii pozwoli zrozu- mieć i wpłynąć na kierunek kolejnych wydań i prio- rytetów, zanim decyzje zapadną. Celem takiego podejścia jest stworzenie środowiska pracy, któ-re pomaga zespołom współpracować, być inno-wacyjnymi  i  tworzyć  oprogramowanie  wyso- Rysunek 2. Produkty bazujące na platformie IBM Rational Jazz 5
  4. 4. •  Zakłada się, że istnieje otwarty, elastyczny,  rozproszony model danych. Nie zakłada się  Odniesienia natomiast, że istnieje jeden model danych,  który jest centralnie zarządzany, ani że każ- • http://www-01.ibm.com/software/rational/jazz/ de narzędzie musi rozumieć cały model da- • http://jazz.net/ • http://jazz.net/library/LearnItem.jsp?href=content/docs/platform-overview/index.html nych w celu udziału w projekcie. • http://www.rodenas.org/blog/2009/04/20/from-the-eclipse-platform-to-the-ibm-rational- •  Pozwala narzędziom na to, by zostały zaim- jazz-platform/ plementowane w dowolnym języku progra- • http://www.youtube.com/watch?v=u_M8jcwuPlg&translated=1 mowania na dowolnej platformie.  Jedno- • http://www.infoworld.com/d/developer-world/ibm-hails-jazz-collaboration-platform-126 cześnie nie narzuca wzorca implementacji   • http://publib.boulder.ibm.com/infocenter/repmhelp/v1r0m0/index.jsp?topic= /com.ibm.jazz.platform.doc/topics/c_jazz-architecture.html przywiązanego do konkretnego języka pro- • http://www-01.ibm.com/software/info/television/html/K936283A96390X11.html gramowania czy technologii platformy. • http://www-903.ibm.com/kr/event/download/200807_364_jazz/s364_01.pdf •  Obsługuje wiele technologii klienckich. In- terfejs użytkownika jest wyborem dla róż- nych narzędzi Jazz. Wspiera także oprogra- te  umożliwiają  narzędziom  implementować    Architecture. Jednak nie każdy produkt Jazz   mowanie bazujące na Eclipse czy Microsoft  swe własne funkcjonalności tak, że będą one  zawiera każdy element z JIA oraz całe podej-  Visual Studio. Inne platformy mogą zostać   dobrze współgrać z innymi narzędziami.  ście Jazz, bowiem całe podejście ciągle ewo-  łatwo zintegrowane, zależnie od żądania. W centrum architektury integracji Jazz znaj- luuje.  W  praktyce,  opisywana  elastyczność   duje się Jazz Team Server. JTS realizuje funda- łączenia  wersji  i  tolerancji  różnych  stopni  Standard OSLC  (Open Services for Lifecycle mentalne usługi Jazz opisane przez JIA, któ- złożoności jest jedną z najważniejszych po- Collaboration) to inicjatywa przemysłu mają- re umożliwiają współpracę grupom narzędzi.   zytywnych cech platformy oraz Jazz Integra-  ca  na  celu  umożliwienie  interoperacyjności   Jazz Team Server może składać się z jednego   tion Architecture. narzędzi i zasobów różnych dostawców. Zwyk-  lub większej liczby fizycznych serwerów, które   Aktualnie w ofercie znajdują się następujące   le klienci korzystają z narzędzi od różnych do- działają jako jeden serwer logiczny. produkty: stawców w celu wychwytywania i zarządza-  W celu ułatwienia wdrażania produktów   nia danymi w całym cyklu życia oprogramo-  zgodnych z JIA dostarczono odpowiednie ze-  •   Rational Requirements Composer, wania. Dane te są zazwyczaj dostępne za po-  stawy narzędzi Jazz. Należą do nich: biblioteki   •    Rational Team Concert, mocą narzędzi, przy pomocy których zostały  specyficzne  dla  danego  języka  umożliwiające   •  Ration Quality Manager. one stworzone, lub przez dostęp do bazy da-  dostęp do różnych usług Jazz Foundation oraz   nych używanej przez to narzędzie. Brak wspól-  dla usług specyficznych dla domeny.  Pozostałe produkty z portfolio IBM Rational  nych  protokołów  dla  wszystkich  zasobów  Większość poziomów integracji JIA jest osią- w przyszłości prawdopodobnie zostaną wcielo- sprawia, że trudno jest zarządzać oprogramo- galnych w dowolnym języku programowania  ne do platformy Jazz, co przyczyni się do jesz- waniem. zdolnym do przetwarzania zapytań HTTP oraz  cze silniejszej ich integracji. Lista produktów  Architektura definiuje zestaw usług zwanych  danych w formacie XML. Oznacza to, że frame-  z pewnością będzie też poszerzona o dodat- Jazz Foundation Services (usługi podstawowe  worki Jazz mogą być rozwijane przez kogokol- kowe nowe projekty. Jazz), które mogą korzystać z podstawowych  wiek i gdziekolwiek.  funkcji platformy do realizacji ogólnych zadań   między narzędziami różnych dostawców, w tym   Podsumowanie W sieci: do administracji projektami, użytkownikami,    IBM  Rational  wraz  z  partnerami  oferuje   • Jazz.net bezpieczeństwa, współpracy, zapytań. Usługi   produkty współdziałające z Jazz Integration   http://www.jazz.net/ • Rational Requirements Composer http://www-01.ibm.com/software/ awdtools/rrc/ • Rational Team Concert http://www-01.ibm.com/software/awdtools/rtc/ • Ration Quality Manager http://www-01.ibm.com/software/ awdtools/rqm/ Bartosz Chrabski IBM Rational Team Leader Jest starszym specjalistą IT pracującym w grupie oprogramowania IBM Polska. Zajmuje się pro- jektowaniem i wdrażaniem systemów zarządza- nia pracą zespołów developerskich oraz technicz- nym wsparciem sprzedaży rozwiązań do zarzą- dzania i wytwarzania oprogramowania z rodziny IBM Rational. Specjalizuje się w technologiach middleware oraz modelowaniu architektury SOA. Doktorant na wydziale Elektroniki i Technik In- formacyjnych Politechniki Warszawskiej. Założy- ciel i lider Łódzkiej Grupy Użytkowników Techno- Rysunek 3. Ekran logowania panelu administracyjnego logii Java (Lodz JUG).6
  5. 5. Zwinność i dyscyplina w podnoszeniu efektywności zespołów projektowych W artykule przedstawiono założenia metodyki projektowania systemów informatycznych łączącą cechy Rational Unified Process oraz metodyk zwinnych takich jak SCRUM i OpenUP. Artykuł przedstawia charaktery- stykę metodyk Rational Unified Process, SCRUM i OpenUP z uwypukle- niem ich cech wspólnych. Artykuł zawiera także analizę wyników zasto- sowania proponowanej metodyki w projekcie informatycznym w kon- tekście podnoszenia efektywności zespołu projektowego pracującego zgodnie z tą metodyką. Podejścia projektowe nie to ma określony zakres funkcjonalności, SCRUM. W ten sposób można uzyskać pro- Zwinne podejście do projektowania systemów którą należy zbudować w określonym czasie ces projektowania systemu informatyczne- informatycznych określa, że istotne elementy i budżecie. Dwa ostatnie elementy w trakcie go, który zapewni odpowiedni poziom dys- w projektowaniu tego typu systemów to [9]: trwania projektu nie ulegają wydłużeniu ani cypliny w prowadzeniu projektu z określo- zwiększeniu. nymi terminami, budżetem oraz adapto- • Procesy i narzędzia, Klient, podpisując kontrakt, oczekuje okre- walność zespołu projektowego do zmienia- • Szczegółowa dokumentacja, ślonych korzyści biznesowych, jakie przynie- jących się w trakcie projektu wymagań. Przy • Negocjacje kontraktowe, sie mu wdrożenie oprogramowania, które za- bliższym spojrzeniu na te metodyki okazuje • Przestrzeganie planu. mawia. Musi ono spełniać określone wymaga- się, że nie są one od siebie tak odległe jak mo- nia funkcjonalne oraz, co bardzo istotne, po- głoby się wydawać. Natomiast, zgodnie z założeniami podejścia za funkcjonalne. W szczególności wymagania zwinnego, jeszcze bardziej istotnymi elemen- związane z wydajnością i bezpieczeństwem. Rational Unified Process tami są: Zdaniem autora, najlepszy efekt uzyskuje Rational Unified Process (RUP) jest iteracyjną się, łącząc najlepsze cechy metodyk tradycyj- metodą wytwarzania oprogramowania. Meto- • Osoby i interakcje, nych takich jak IBM Rational Unified Process dyka RUP ma opinię ciężkiej metodyki. Argu- • Funkcjonujące oprogramowanie, oraz metodyk zwinnych takich OpenUP czy mentuje się to olbrzymim nakładem prac na • Współpraca z klientem, • Dostosowywanie się do zmian. Widać z tego, że podejście zwinne przenosi punkt skupienia z procesu z przypisanymi ro- lami, sztywnego trzymania się szczegółowego planu i nadmiernego dokumentowania decy- zji projektowych na jak najszybsze uzyskiwa- nie funkcjonującego oprogramowania spełnia- jącego zmieniające się potrzeby klienta. W ocenie autora nie oznacza to jednak od- rzucenia procesu projektowania i określonych ról, gdyż role są zdefiniowane w metodykach zwinnych, lecz koncentrację na uzyskaniu efektu końcowego, jakim jest funkcjonujące zgodnie z potrzebami klienta oprogramowa- nie. Praktyka projektowa pokazuje, że klienci, podpisując kontrakt, mają jasno zdefiniowa- ne cele tworzenia systemu. Oprogramowa- Rysunek 1. Struktura RUP8
  6. 6. Zwinność i dyscyplinawytwarzanie dokumentacji projektu. We- Czas trwania iteracji nie jest ściśle określony. Metodyka Rational Unified Process uważanadług niektórych [11] prace nad dokumenta- RUP rekomenduje, że iteracja powinna trwać jest za metodykę ciężką ze względu na tworzo-cją zajmują do 50% wszystkich prac projek- od dwóch do sześciu tygodni [8]. Planowanie ną dużą liczbę dokumentów. Dotyczy to jedtowych. Tego typu wyliczenia wskazują na iteracji zgodnie z metodyką RUP powinno nak pełnej metodyki RUP, która nie powinnastosowanie metodyki RUP w pełnej posta- składać się z czterech kroków: być w takiej postaci stosowana w projektach.ci, co jest pomysłem delikatnie mówiąc nie- Należy pamiętać o pierwszej zasadzie RUProzsądnym. • określenie zakresu iteracji, – dostosowanie procesu – i dobrać poziom U podstaw RUP leży sześć kluczowych re- • określenie kryteriów oceny iteracji, dokumentowania procesu do wielkości i zło-guł projektowania systemów informatycz- • przypisanie odpowiedzialności do po- żoności projektu.nych ukierunkowanego na zastosowanie biz- szczególnych czynności.nesowe: • określenie czynności wykonanych pod- SCRUM czas iteracji, Scrum to, zgodnie z Agile Manifesto, zwinna• dostosowanie procesu, metodyka prowadzenia projektów. Najczęściej• bilansowanie przeciwstawnych prioryte- Cele iteracji zależą od etapu, w którym rozpa- jest ona wykorzystywana w projektach informa- tów udziałowców, trywana iteracja jest przeprowadzana. tycznych. SCRUM używany jest w projektach• współpraca między zespołami, Pierwszym etapem w metodyce RUP jest charakteryzujących się wysokim poziomem• demonstrowanie wartości w sposób itera- etap rozpoczęcia. Głównymi celami etapu roz- zmienności wymagań lub w przypadku przed- cyjny, poczęcia są: określenie zakresu sytemu, przed- sięwzięć o wysokim stopniu innowacyjności.• dostosowanie poziomu abstrakcji, stawienie architektury kandydującej systemu, Metodyka skupia się na:• ciągłe skupienie na jakości. określenie listy ryzyk. W etapie opracowania głównymi celami są • dostarczaniu kolejnych, coraz bardziej do-Za regułami tymi kryją się podstawowe dla zweryfikowanie architektury systemu oraz pracowanych wyników projektu,inżynierii oprogramowania praktyki: rozwiązanie głównych ryzyk. Szczegółowemu • włączaniu się przyszłych użytkowników opisowi i implementacji w etapie opracowania w proces wytwórczy,• wytwarzaj iteracyjnie, powinny podlegać te przypadki użycia, które • samoorganizacji zespołu projektowego.• zarządzaj wymaganiami, są krytyczne z punktu widzenia architektury,• używaj architektury komponentowej, oraz te, które realizują funkcjonalność najistot- Zazwyczaj zespół SCRUM składa się z 5-9• modeluj wizualnie (UML2.0), niejszą dla udziałowców. osób. Dobrze, gdy ma on charakter interdys-• stale weryfikuj jakość, Celem etapu budowy jest wytworzenie sta- cyplinarny i składa się z osób reprezentują-• zarządzaj zmianami. bilnej wersji systemu z pełną wymaganą funk- cych różne umiejętności. Osoby uczestniczące cjonalnością. Etap budowy jest najbardziej w zespole nie mogą uczestniczyć w innychNa podkreślenie zasługują praktyki związane pracochłonnym z etapów i zajmuje przecięt- zespołach. Główne role w projekcie to: Mistrzz zarządzaniem wymaganiami, modelowaniem nie 50% czasu trwania całego projektu. Młyna (ang. Scrum Master), Właściciel Pro-wizualnym z UML oraz używaniem architek- Celem etapu przekazania jest dostarczenie duktu (ang. Product Owner) i Członkowietury komponentowej. końcowej wersji produktu użytkownikowi. Zespołu (ang. The Team). Struktura procesu RUP jest dwuwymiaro-wa, co przedstawia Rysunek 1. Wymiar pozio-my pokazuje ułożenie projektu w czasie z po-działem na etapy i iteracje. Wymiar pionowyukazuje dyscypliny procesu RUP. W ramachRUP, występuje dziewięć dyscyplin, począw-szy od modelowania biznesowego a skończyw-szy na utrzymaniu środowiska produkcyj-nego. W każdej z dyscyplin określone są czyn-ności i role odpowiedzialne za wykonanietych czynności, produkty potrzebne do reali-zacji czynności, a także produkty będące wy-nikiem realizacji czynności [6]. Z punktu widzenia planowania projektu is-totne są dwa plany: Plan przedsięwzięcia, Planiteracji, za które odpowiada Kierownik pro-jektu. Plan przedsięwzięcia zawiera takie in-formacje jak terminy głównych kamieni mi-lowych faz, profil zespołu przedsięwzięcia,terminy pomniejszonych kamieni milowych.Plan iteracji jest planem szczegółowym i ty-czącym się aktualnej iteracji. Plan iteracji za-wiera terminy iteracji, jej zakres oraz kryteriaodbioru. Podczas każdej iteracji realizowanesą czynności związane z dyscyplinami po-trzebnymi do jej realizacji. Udział czynnościz poszczególnych dyscyplin zmienia się wrazz postępem procesu. Rysunek. 2 Przebieg prac zgodnie ze SCRUM [13] 9
  7. 7. Zespół projektowy pracuje w określonym gerować w prace zespołu. Nie powinno się OpenUP przedziale czasowym zwanym przebiegiem także zmieniać zakresu przebiegu. Przebieg Metodyka Open Unified Process, w skrócie (ang. sprint). Efektem przebiegu za każdym prac zgodnie ze SCRUM został przedstawio- OpenUP, jest częścią projektu Eclipse Pro- razem powinno być dostarczenie użytkowni- ny na Rysunku 2. cess Framework (EPF). OpenUP dostarcza kom kolejnego działającego produktu. Zasadą Zespół z założenia jest samoorganizujący się zbiór dobrych praktyk iteracyjnego wytwa- jest to, że prace wykonywane w ramach prze- i nie ma odgórnego przypisywania zadań do rzania oprogramowania. OpenUP proponuje biegu muszą skutkować dostarczeniem nowej poszczególnych członków zespołu. Samodzielnie podzielić cały proces wytwarzania oprogramo- funkcjonalności. Przebieg może trwać od 2 do dokonują oni wyboru realizowanych zadań, wania na trzy następujące obszary: 6 tygodni. Zaleca się stosowanie przebiegów według wspólnych ustaleń i umiejętności. o stałych długościach. Naczelną zasadą metodyki jest przeprowa- • Cykl Życia Projektu (ang. Project Lifecycle), W pierwszym etapie tworzona jest lista dzanie codziennych (około 15-minutowych) • Cykl Życia Iteracji (ang. Iteration Lifecycle), wymagań użytkownika. Właściciel projektu spotkań (ang. scrum meeting), na których oma- • Mikro-Przyrosty (ang. Micro-Increments). jest też zobowiązany do przedstawienia prio- wiane są zadania zrealizowane poprzedniego rytetów wymagań oraz głównego celu prze- dnia i problemy występujące przy ich realizacji Podział ten oraz jego najważniejsze aspekty biegu. Po tym formułowany jest rejestr wy- oraz zadania do wykonania w dniu spotkania. przedstawia Rysunek 3. magań (ang. Product Backlog). Następnie wy- Przebieg kończy się przeglądem przebiegu Każdy z obszarów posiada artefakt, który bierane są zadania o najwyższym priorytecie, (ang. sprint review), na którym prezentowany opisuje jego zakres oraz prace do wykonania. a jednocześnie przyczyniające się do realizacji ce- jest wynik pracy zespołu przez prezentowanie Najbardziej ogólnym obszarem jest Cykl Ży- lu projektu. Szacuje się czas realizacji każdego za- produktu wykonanego podczas przebiegu. Po- cia Projektu, dokumentem z nim związanym dania. Lista zadań wraz z oszacowaną czaso- winni w nim uczestniczyć wszyscy zaintere- jest Plan projektu. Cykl Życia Projektu dostar- chłonnością nosi nazwę rejestru zadań przebie- sowani projektem. Po omówieniu produktu cza udziałowcom, członkom zespołu widocz- gu (ang. Sprint Backlog). W trakcie realizacji ustalany jest termin spotkania planistyczne- nych punktów synchronizacji oraz punktów przebiegu Właściciel Produktu nie może in- go do następnego przebiegu. decyzyjnych w całym projekcie. Proces wytwarzania oprogramowania, zgod- nie z OpenUP, podobnie jak RUP, składa się z czterech etapów: • Rozpoczęcia (ang. Inception), • Opracowania (ang. Elaboration), • Budowy (ang. Construction), • Przekazania (ang. Transition). Etapy kończą się kamieniami milowymi. Każdy z etapów składa się z jednej lub wielu iteracji. Na podstawie dokumentu Plan pro- jektu tworzony jest dokument Plan iteracji. Artefakt ten związany jest z obszarem Ope- nUP, jakim jest Cyklu Życia Iteracji. Obszar Cykl Życia Iteracji zapewnia zbiór praktyk opi- sujących sposób przeprowadzenia iteracji ukie- runkowanej na zespół, dostarczającej przyrosto- we wartości udziałowcom w przewidywalny spo- sób. Iteracja wymusza na zespole skoncentrowa- nie swoich prac na dostarczeniu, co kilka tygodni w pełni przetestowanej, kolejnej części produktu. Przebieg iteracji zgodny z OpenUP przedstawio- ny jest na Rysunku 4. Rysunek 3. Obszary OpenUP [2] Postęp iteracji widoczny jest przez zakoń- czenie kolejnych mikro-przyrostów (ang. mi- Planowanie Stabilny tygodniowy Stabilny wyrób Recenzja iteracji wyrób iteracji iteracji cro-increments). Na początku iteracji organizo- wane jest spotkanie dotyczące planu iteracji. Spotkanie takie trwa do kilku godzin. Inicja- Kilka godzin Kilka godzin lizacja iteracji trwa od jednego do dwóch dni. Czas ten poświęcony jest na uszczegółowienie Planu iteracji, dogłębne zrozumienie zależno- ści logicznych wytwarzanych elementów oraz ich wpływu na architekturę. Większość czasu Kilka dni iteracji poświęcona jest na wykonywanie mi- kro-przyrostów, które dostarczają przetesto- wany kod oraz zatwierdzone artefakty. Dla Berpośrednie planowanie Ciągłe mikro-przyrosty Ciągła naprawa błędów uzyskania większej dyscypliny, pod koniec każ- i architektura naprawa błędów i budowa mikro-przyrosty i budowa dego tygodnia należy zapewnić stabilny kod. Rysunek 4. Iteracja wg OpenUP Umożliwia to wczesne wykrycie i rozwiązanie10
  8. 8. Zwinność i dyscyplinaproblemów. Ostatni tydzień lub kilka ostat-nich dni iteracji zazwyczaj poświęconych jestw dużej mierze na poprawę wcześniej ziden-tyfikowanych błędów. Celem jest dostarcze-nie, na koniec iteracji, wysokiej jakości pro-duktu zawierającego wymaganą funkcjonal-ność. Iteracje kończą się oceną produktu, któ-ry został podczas niej wytworzony. W oceniebiorą udział zainteresowane strony. Iteracjew różnych etapach różnią się od siebie wyko-nywanymi czynnościami oraz celami. Celew poszczególnych fazach są podobne do celówRUP. Metodyka OpenUP jest lekką metodyką ite-racyjnego wytwarzania oprogramowania. Prze-znaczona jest dla zespołów składających sięz 3-6 sześciu osób, oraz projektów, które trwa-ją około sześciu miesięcy. Szczegółowe po-równanie RUP i OpenUP zawarto w [5].Zwinny RUPW projektowaniu systemów informatycznychistotnym jest element spełniania wymagań po- Podstawowym jest zastosowanie głównych weryfikacji architektury, rozwiązania ryzykstawionych przez udziałowców. założeń metodyk takich jak RUP na pozio- projektowych, przewidywalnego dostarcza- Z praktyki projektowej wynikają niezbicie mie wyższym projektu: etapy. Natomiast na nia kolejnych przyrostów oraz przygotowane-dwa fakty. Zbyt sztywne trzymanie się harmo- niższym poziomie – iteracji, mikro-przyro- go przekazania systemu użytkownikowi koń-nogramu i skupienie na tworzeniu szerokiej li- stu – należy stosować założenia charaktery- cowemu.sty dokumentów może prowadzić do olbrzy- zujące metodyki zwinne takie jak SCRUM Elementem, jaki należy zrealizować przy za-mich kosztów i nikłych efektów w sensie wy- i OpenUP. stosowaniu RUP w projektach, jest jasne zde-tworzonego produktu końcowego, jakim jest Do zasad RUP, które warto stosować w pro- finiowanie zakresu czynności i produktówfunkcjonujący system informatyczny. Z dru- jektach informatycznych, należą: wchodzących w zakres metodyki stosowanejgiej strony brak jakiejkolwiek dokumentacji w określonym projekcie. Podstawowe w RUPi duża skłonność do wprowadzania zmian na • iteracyjne wytwarzanie, jest ograniczenie zbioru wytwarzanych doku-życzenie udziałowców prowadzi do nadmier- • modelowanie wizualne (UML), mentów oraz modeli do tych naprawdę istot-nego rozprzestrzeniania się zakresu systemu, • modelowanie architektury (wybrane wi- nych w określonym projekcie. Zapewni to od-wielokrotnego przepisywania kodu i jego testo- doki), ciążenie zespołu projektowego od nadmierne-wania i w wyniku także wysokich kosztów wy- • zarządzanie wymaganiami w sposób ciągły. go dokumentowania i modelowania oraz po-tworzenia systemu informatycznego. zwoli na skupienie się na wytwarzaniu opro- W związku z powyższym istotnym jest od- Do zalet RUP należy stosowanie podziału pro- gramowania.powiednie skonfigurowanie procesu projekto- jektu na etapy i iteracje. Zastosowanie czte- Przy projektowaniu systemów informa-wania systemu informatycznego. Kluczowym, rech etapów z jasno określonymi celami i kry- tycznych istotne są kluczowe role definiowa-zdaniem autora, jest łączenie zalet podejścia teriami przejścia do kolejnego etapu przyczy- ne w RUP:zdyscyplinowanego z podejściem zwinnym. nia się do wczesnego zdefiniowania zakresu, • Kierownik projektu, 5 • Główny analityk, 5 • Główny architekt, • Projektant bazy danych, Średni czas realizacji jednego przypadku 4 • Kierownik testów. Role te koordynują główne prace w zespole pro- uzycia iteracji 3 jektowym i mają największy wpływ na kreowa- nie końcowego rozwiązania, jakim jest sys- tem informatyczny. Porównując z metody- 2 ką SCRUM, można zauważyć podobieństwo 1,7 ról Kierownik projektu i Główny Analityk z RUP oraz Mistrz Młyna i Właściciel Produk- 1 tu ze SCRUM. 0,7 SCRUM czy OpenUP może wnieść do projek- 0 tu, paradoksalnie, zdyscyplinowane wytwarza- I iteracja II iteracja III iteracja nie praktycznie codziennych mikro-przyrostów Iteracje oprogramowania. Efektem takiej organizacji pracy jest bardziej stabilne oprogramowanieRysunek 5. Wykres średniego czasu realizacji przypadku użycia w iteracji na koniec iteracji. Należy jednak pamiętać, 11
  9. 9. aby nie popaść w zbyt szczegółowe testowanie Pierwszy z widoków architektonicznych sta- mi Kolejowymi i Drużynami Trakcyjnymi poszczególnych mikro-przyrostów. Z drugiej nowi widok Przypadków użycia. W ramach te- w PKP CARGO S.A. – zespół 50 osób. strony testowanie oprogramowania tylko przez go widoku wykonuje się Model przypadków tworzących je programistów może prowadzić użycia. Model ten stanowi specyfikację wy- Najistotniejszą cechą wspólną tych projek- do pozostawienia w kodzie zbyt wielu ukry- magań budowanego systemu. tów informatycznych jest to, że zakończyły się tych błędów. Wyjściem jest stosowanie testo- W widoku Logicznym przedstawiana jest w z góry określonym czasie, dostarczono wy- wania jednostkowego na poziomie przyrostu, struktura oprogramowania oraz sposób jego maganą funkcjonalność oraz zrealizowano to a testowania wersji włącznie z testami regresyj- działania. Budowany jest w nim Model pro- w ramach ustalonego wcześniej budżetu. nymi na poziomie iteracji. jektowy oraz Model bazy danych. Kluczowym przy stosowaniu podejścia Istotnym jest widok Wdrożeniowy poka- Dalej przedstawiono analizę wyników budowy SCRUM jest znajomość jasno zdefiniowa- zujący system informatyczny na środowisku fragmentu systemu informatycznego dla Kan- nych wymagań dla przebiegu. W roli Właści- uruchomieniowym z fizycznymi serwerami celarii Prawniczej [10]. System ten tworzony ciela Produktu ze SCRUM może występować oraz środowiskami uruchomieniowymi. Bu- był w architekturze Java EE, przy wykorzysta- Analityk z RUP zajmujący się określonym wy- dowany jest w nim Model wdrożeniowy. niu dostosowanej konfiguracji RUP. Cały pro- maganiem funkcjonalnym – przypadkiem Wczesne zdefiniowanie i zweryfikowanie ces składał się z trzech iteracji. W iteracjach zo- użycia. Analityk ściśle współpracuje z Człon- architektury systemu informatycznego za- stały uzyskane wartości następujących wskaź- kami Zespołu w celu doprecyzowania wyma- pewnia minimalizację ryzyk projektowych ników efektywności zespołu projektowego: gań realizowanych w przebiegu. oraz minimalizację kosztów projektu. Zgod- Zasada, aby nie przedłużać czasu trwania itera- nie z RUP, pełen zespół projektowy powoływa- • średni czas realizacji przypadku użycia, cji, jest wspólna, zarówno dla metodyk RUP, jak ny jest dopiero w fazie budowy, po wcześniej- • liczba zaimplementowanych przypadków i SCRUM. Zarówno RUP, jak i SCRUM pod- szej weryfikacji architektury przez niewielki użycia w iteracji, kreślają znaczenie oceny iteracji (przebiegu) zespół doświadczonych specjalistów. • liczba klas wytworzonych w iteracji, dla lepszego dalszego planowania projektu. • liczba klas ponownie użytych w iteracji, Drugim podstawowym elementem pro- Zwinny RUP w praktyce • liczba wszystkich klas użytych w iteracji, cesu wytwórczego jest architektura systemu Przedstawione powyżej podejście zostało • liczba tworzonych metod w iteracji dla re- informatycznego. Jest to element szczególnie wstępnie zweryfikowane w projekcie uczel- alizacji przypadku użycia. podkreślany w metodyce RUP. Metodyka RUP nianym systemu informatycznego dla Kance- w pełnej postaci zakłada modelowanie sys- larii Prawniczej. Następnie zostało zastosowa- Dzięki wykorzystaniu doświadczenia oraz już temu informatycznego z punktu widzenia ne w projektach informatycznych istotnie róż- istniejących elementów systemu, czas potrzeb- modelu architektonicznego „4+1”[7]. Model niących się od siebie: ny na implementacje przypadku użycia w ko- ten obejmuje następujące widoki architekto- lejnych iteracjach uległ znacznemu skróceniu. niczne systemu informatycznego: Przypad- • Projekt dla Służby Zdrowia RP „Mode- Średni czas realizacji przypadku użycia w ko- ków użycia, Logiczny, Wdrożeniowy, Proce- lowanie repozytorium i analiza efektyw- lejnych iteracjach został przedstawiony na Ry- sów, Implementacyjny. ności informacyjnej wytycznych i ścieżek sunku 5. W większości projektów informatycznych klinicznych w służbie zdrowia”, nr ref.: Każda z iteracji trwała tydzień (pięć dni ro- istotne jest modelowanie architektury syste- POIG. 01.03.01-00-145/08, Program Opera- boczych). W pierwszej iteracji został zreali- mu informatycznego z punktu widzenia na- cyjny „Innowacyjna Gospodarka” – zespół zowany jeden przypadek użycia, w drugiej, stępujących widoków architektonicznych mo- 30 osób. w tym samym czasie, zaimplementowane zo- delu „4+1”: Przypadków użycia, Logicznego, • Etap I wdrożenia Zintegrowanego Syste- stały trzy przypadki użycia. Wdrożeniowego. mu Wspomagającego Zarządzanie Pojazda- W trzeciej iteracji liczba wykonanych przy- padków użycia wzrosła do siedmiu. Oznacza to, że w tym samym okresie możliwe było do- starczenie większego zakresu funkcjonalności 25 systemu, co przekłada się na wzrost postępu prac i tym samym podniesienie poziomu efektyw- 20 21 ności zespołu projektowego. Efekt ten wynika: • ze zwiększającego się wskaźnika wtórne- 15 go użycia kodu w kolejnych iteracjach, Liczba klas • z nabywania doświadczenia, umiejętno- 12 ści i wiedzy dotyczącej stosowanej tech- 10 nologii, 9 9 • z wczesnej stabilizacji architektury systemu. 6 5 Wraz z postępem prac wzrastała także liczba klas powtórnie użytych w iteracji. W drugiej 0 0 iteracji liczba ta wyniosła 6, a w trzeciej 12. I iteracja II iteracja III iteracja Rysunek 6 przedstawia wykres liczby klas po- nownie użytych oraz wszystkich klas wykorzy- Iteracje stanych podczas implementacji w poszczegól-  Liczba klas uzytych w iteracji  Liczba wszystkich klas uzytych w iteracji nych iteracjach. Liczbę klas wytworzonych i powtórnie uży- Rysunek 6. Wykres liczby klas ponownie użytych oraz wszystkich klas wykorzystanych w iteracjach tych w iteracji odniesiono także do liczby wszyst-12
  10. 10. Zwinność i dyscyplinakich klas użytych w iteracji. Uzyskano procen-towy udział obydwu tych liczb w liczbie wszyst- Bibliografiakich klas użytych w iteracji. Zostało to przedsta- • [1] Barnes J., Implementing the IBM Rational Unified Process and Solutions. A Guide to Improvingwione na wykresie na Rysunku 7. Your Software Development Capability and Maturity., IBM Press, 2007, Ciekawe wyniki uzyskano również, obser-wując wskaźnik pokazujący nakład pracy, • [2] Dokumentacja OpenUP Version 1.5.0.1,wyrażony za pomocą liczby tworzonych me- • [3] Fowler M., UML Distilled Third Edition, Addison-Wesley, 2005,tod w iteracji dla realizacji przypadku użycia. • [4] Kan S. H., Metryki i modele w inżynierii jakości oprogramowania, Mikom, 2006,W pierwszej iteracji należało utworzyć 118 • [5] Kroll P., MacIsaac B., Agility and discipline made easy, Addison-Wesley, 2006,metod, aby zrealizować jeden przypadek • [6] Kroll P., Krutchten P., Rational Unified Process od strony praktycznej, WNT, Warszawa 2007,użycia, w drugiej 42 metody, aby zrealizo- • [7] Kruchten P., The Rational Unified Process, An Introduction, Addison-Wesley, USA, 1999,wać 3 przypadki użycia, w trzeciej 71 metod, • [8] Krutchten P., Rational Unified Process od strony teoretycznej, WNT, Warszawa 2007,aby zrealizować 7 przypadków użycia. Licz- • [9] Manifesto for Agile Software Development, www.agilemanifesto.org,ba tworzonych metod w iteracji dla realizacji • [10] Olszewski J., Metoda iteracyjnej budowy systemów informatycznych w architekturze J2EE,przypadku użycia kształtowała się następują- praca magisterska WAT, 2009, kierownik dr inż. Tomasz Górski,co w iteracjach: • [11] RUP (Rational Unified Process), www.javatech.com.pl/rup.html, • [12] Schwaber Ken, Agile Poject Management with Scrum, Microsoft Press, Washington 2004,• I iteracja - 118 metod, • [13] Scrum in five minutes, www.softhouse.se/Uploades/Scrum_eng_webb.pdf,• II iteracja - 14 metod, • [14] Takeuchi Hirotaka, Nonaka Ikujiro, The New Product Development Game, Harvard Business • III iteracja - 10 metod. Review, 01-02.1986.Realizacja przypadku użycia w kolejnychiteracjach odbywała się mniejszym kosztem ści zespołu projektowego. Postęp prac zwięk- Projekty realizowane zgodnie z przedstawio-nakładu prac, m.in. dzięki ponownemu uży- szał się w każdej kolejnej iteracji przy jednocze- ną metodyką charakteryzowały się następują-ciu już istniejącego kodu. W pierwszej itera- snym zmniejszaniu się nakładu prac. cymi cechami:cji stworzona została podstawowa architek- • podniesienie przewidywalności projektu,tura systemu, co pociąga za sobą potrzebę Podsumowanie • wczesna stabilizacja architektury systemuimplementacji klas i ich metod stanowiących W artykule została zaproponowana metoda ite- informatycznego,rdzeń systemu. racyjnej budowy systemów informatycznych • sukcesywne i przewidywalne dostarczanie Istotnym aspektem jest fakt, że zastosowa- łącząca Rational Unified Process i SCRUM. produktów projektu,nie podejścia iteracyjnego umożliwia wcze- W metodzie tej zaproponowano podejście • podniesienie ponownego użycia klas w sys-sne nabywanie doświadczenia i umiejętności, ukierunkowane na architekturę i łączenie wy- temie informatycznym,co przekłada się na podniesienie efektywno- twarzania iteracyjnego z zaletami przebiegów • obniżenie liczby ponownie przepisywa-ści zespołu projektowego. Ponadto, wcześnie SCRUM. nych klas,zdefiniowana i zweryfikowana architektura Metodyka ta została wykorzystana podczas • skrócony czas realizacji przypadku użycia,systemu niweluje ryzyko jego technicznej re- budowy fragmentu systemu informatyczne- • zmniejszenie liczby metod potrzebnych doalizacji. go wspomagającego pracę kancelarii prawni- realizacji przypadku użycia. Otrzymane wyniki świadczą jednoznacznie czej, ale także podczas realizacji w/w projek-o podnoszeniu w trakcie projektu efektywno- tów komercyjnych. Łączenie dwóch elementów: elastycznej or- ganizacji zespołu projektowego oraz ścisłej kontroli architektury systemu informatycz- 100% nego prowadzi do podnoszenia efektywności zespołu projektowego. Należy podkreślić, że 90% podstawowym widokiem architektonicznym 80% 33% jest widok Przypadków użycia. Kluczowym 43% jest utrzymywanie ciągłego porozumienia nad 70%Udział procentowy klas stworzonych zebranym zestawem wymagań pomiędzy Ze- i klas re-uzywanych w iteracji 60% społem projektowym a Zamawiającym i Użyt- 50% 100% kownikiem końcowym. 40% dr inż. Tomasz Górski 30% 67% Adiunkt w Instytucie Systemów Informatycznych, 57% Wydziału Cybernetyki, WAT. Prowadzi firmę Right- 20% Solution™ (Autoryzowane Centrum Edukacyjne 10% IBM Rational) zajmującą się projektowaniem sys- 0% temów informatycznych zgodnie z Rational Uni- I iteracja II iteracja III iteracja fied Process w architekturze SOA. Certyfikowany Iteracje instruktor RUP. Zainteresowania naukowe i prace komercyjne skoncentrowane na procesie projek-  Klasy re-użyte w iteracji  Klasy stworzone w iteracji towania systemów informatycznych a w szcze- gólności na projektowaniu platform integracyj-Rysunek 7. Wykres przedstawiający udział procentowy klas wytworzonych oraz klas ponownie nych dla organizacji sektora publicznego.użytych w iteracjach e-mail: tomasz.gorski@rightsolution.pl 13
  11. 11. Wywiad z Januszem Górskim rozmawia Bartosz Chrabski Czy inżynieria oprogramowania nadal potrafi w sposób umożliwiający „zwinne” nadążanie i stanu obecnego niż wizją jakiejś nowej zaskaku- nas naprawdę zaskoczyć nowymi odkryciami i po- za zmianami, architektury SOA i nacisk na in- jącej zmiany. Przewiduję tu narastającą tenden- dejściami do już znanych od lat problemów ? tegrację procesów biznesowych oraz poszukiwa- cję do poszerzania perspektywy w postrzeganiu Celem inżynierii oprogramowania jest skutecz- nie abstrakcji umożliwiających reprezentowanie oprogramowania w wymiarze systemowym ne rozwiązywanie, przy zastosowaniu środków oprogramowania w sposób niezależny od jego (a więc bardziej systems engineering niż software z dziedziny technologii informacyjnych, proble- technicznej realizacji. W coraz większym stopniu engineering) i w związku z tym większy nacisk na mów z praktycznie dowolnych dziedzin apli- rozpoznawane jest również znaczenie czynnika poza-funkcjonalne własności związane z gwa- kacyjnych. A więc na przykład rozwiązanie pro- ludzkiego, zarówno po stronie analizy i oceny rancjami takimi jak bezpieczeństwo (safety), za- blemu ułatwienia dostępu klientów do usług systemów, jak i po stronie wytwórczej. bezpieczenie (security), prywatność czy zdolność bankowych, niezależnie od ich lokalizacji geogra- W mojej ocenie po stronie technologicznej systemów do przeżycia, pomimo niesprzyjają- ficznej względem siedziby i oddziałów tego ban- jest większa szansa na zaskoczenie. Technologie cych warunków wewnętrznych czy zewnętrz- ku. Rozwiązanie polega tu na wdrożeniu ban- informacyjne już nie raz dowiodły, że ich roz- nych. W tendencję tę wpisuje się również więk- kowości internetowej. Jeżeli zgodzimy się co do wój może przyczynić się do zmian o charakte- sza koncentracja na użytkownikach i dostar- takiego rozumienia inżynierii oprogramowania, rze rewolucyjnym. Przyczyną jest to, że mogą czanej im wartości dodanej. Spowoduje to ros- to zaskoczenie, o które Pani pyta, może pojawić one otwierać nowe i nieprzewidziane wcześniej nący nacisk na przekraczanie barier w komuni- się z dwóch źródeł: od strony problemów, które możliwości w dziedzinach problemowych, tak kacji i współpracy między reprezentantami są przedmiotem zainteresowania, oraz od stro- jak Internet otworzył drogę do nowych modeli różnych dziedzin i organizacji oraz rosnące zna- ny środków, które są wykorzystywane podczas świadczenia usług i w znacznym stopniu uwol- czenie pracy grupowej. Szybkość i zakres zmian rozwiązywania tych problemów. nił biznes od ograniczeń geograficznych, a tele- oraz konieczność nadążania za zmianą utrzy- Tendencje po stronie problemów to przede fonia komórkowa zrewolucjonizowała struktu- mają zainteresowanie metodami „zwinnymi” wszystkim poszerzający się ich zakres, zmien- rę komunikacyjną w wymiarze indywidualnym oraz traktowanie przedsięwzięć informatycz- ność, presja czasu oraz otwartość. i biznesowym. Takie zmiany w infrastrukturze nych jako procesów, które bardziej nadążają za Poszerzanie zakresu oznacza, że rozwiązania inspirują nowe i gwałtownie rozwijające się po- „ruchomym celem” niż są realizowane według informatyczne są stosowane w nowych obszarach trzeby, a jednocześnie tworzą warunki do no- przygotowanego wcześniej szczegółowego pla- i do problemów, które nie były wcześniej objęte wych i bardziej skutecznych sposobów zaspokaja- nu. Utrzyma się tendencja do integracji i zwią- informatyzacją. Zmienność oznacza, że identy- nia tych potrzeb. Co będzie takim „zapalnikiem” zany z tym wzrost złożoności systemów. Z jed- fikacja problemu praktycznie nigdy się nie koń- w najbliższej przyszłości? SOA i integracja proce- nej strony wymagać to będzie środków technicz- czy – trzeba liczyć się z tym, że możemy jedynie sów biznesowych? Cloud computing jako nowy nych wspomagających taką integrację, z drugiej lepiej lub gorzej nadążać za zmianami. Odpowie- i uniwersalny model dostępu do usług IT? A mo- zaś strony niezbędne będą abstrakcje i metody dzią na to jest położenie większego nacisku na że będzie to coś, co się „narodzi” na przecięciu in- umożliwiające przygotowanie tworzonych sys- współpracę z udziałowcami reprezentującymi formatyki i biotechnologii? Trudno przesądzać, temów do przyszłej integracji oraz zapanowa- dziedzinę problemową oraz utrzymywanie cią- tym bardziej że ludzie wielokrotnie już dowiedli, nie nad wynikającą stąd złożonością. Wiąże się głości tej współpracy w pełnym cyklu życia opro- że przewidywanie przyszłości nie bardzo im się z tym również zagadnienie gotowych komponen- gramowania. Presja czasu powoduje, że inżynie- udaje. Ja przewiduję przesuwanie się inżynierii tów (COTS – Commercial off-the-shelf), czy sze- ria oprogramowania szuka metod umożliwiają- oprogramowania w stronę „inżynierii systemów” rzej, wielokrotne wykorzystanie istniejących cych szybką dostawę rozpoznawalnej dla klienta i związany z tym rosnący rynek pracy dla spe- już komponentów (software re-use). Rosnącego wartości dodanej, nawet jeżeli będzie ona dostar- cjalistów łączących kompetencje z dziedzin znaczenia będzie nabierać integracja systemów czana w sposób niepełny i potem uzupełniana aplikacyjnych z umiejętnościami obszaru anali- (systems-of-systems) nie tylko w wymiarze funk- kolejnymi przyrostami. Te dwie ostatnie ten- zy, (re)inżynierii procesów biznesowych oraz ar- cjonalnym, ale również (a może nawet bardziej) dencje są odzwierciedlone w tzw. podejściach chitektury oprogramowania i infrastruktury ko- w wymiarze związanych z nimi gwarancji poza- „zwinnych”. Otwartość na integrację oznacza, munikacyjnej. Natomiast kompetencje odnoszą- funkcjonalnych (takich jak bezpieczeństwo, że powstające rozwiązania techniczne nie mogą ce się do wytwarzania oprogramowania w sensie dostępność czy niezawodność). Integracja ta bę- być „zamknięte” i użytkowane w izolacji. Dy- „umiejętności programowania” będą nie tyle za- dzie musiała również uwzględniać istnienie opro- namika w świecie biznesu, w sferze społecznej nikać, co lokalizować się w miejscach, gdzie takie gramowania „odziedziczonego” (legacy systems). czy w gospodarce skutkuje potrzebą integrowa- oprogramowanie będzie tworzone. Czy zmiany nia istniejących i nowych systemów. te przybiorą charakter rewolucyjny, czy będzie Jakie obszary według Pana są najmniej zbadane W wymienionych wyżej obszarach bardziej to ewolucja – zobaczymy. i wymagają ciągłej pracy nad analizą tej dziedziny ? niż o rewolucji trzeba raczej mówić o ewolucji, Pole do badań jest bardzo obszerne. W końcu ale ewolucji, która ostatnio gwałtownie przy- Czy w ostatnich latach powstały jasno identyfi- mamy do czynienia z dziedziną, która nie „żyje” spieszyła. kowalne trendy w dziedzinie inżynierii oprogra- jeszcze nawet jednego pełnego stulecia. Której Wśród tendencji po stronie środków metodo- mowania, na które warto jest zwracać uwagę ? zakres oraz spektrum możliwych zastosowań są logicznych i technicznych można wyróżnić poło- Niewątpliwie jest ich kilka. Wszystkie one wciąż dalekie od pełnej identyfikacji. Która wciąż żenie większego nacisku na ciągły kontakt z klu- w jakiś sposób narastają stopniowo, a więc ich nie ma wspólnego i powszechnie akceptowane czowymi udziałowcami, zarządzanie projektem identyfikacja jest bardziej ekstrapolacją historii go systemu pojęć i związanego z nim języka. Nie14
  12. 12. Wywiad z Januszem Górskimdo końca wiemy, jak powtarzać sukces w budo Jakie wyzwania według Pana stają przed nowo- w oderwaniu od kontekstu wspierającego ichwie oprogramowania, nie rozumiemy i nie uz- czesnymi narzędziami wspierającymi proces wy- rozwój i zastosowania. Wielokrotnie obserwowa-godniliśmy kryteriów dla takiego sukcesu, mamy twórczy na rynku ? łem narzędzia (i związane z nimi metody), któ-do czynienie z budulcem, który jest ulotny i mo- Oczywistym wydaje się postulat, by narzędzia re szybko obumierały, gdy kończyło się związaneże zmieniać swoje własności, nie mamy satysfak- wspierały osiąganie celów, do których dążą ich z nimi wsparcie. Oprócz tych kryteriów ogólnychcjonującej wiedzy na temat procesów, w ramach użytkownicy. Tak więc cele wydają się być nad- jest oczywiście bardzo ważną sprawą, by narzę-których powstaje i jest eksploatowane oprogra- rzędne nad narzędziami, tzn. narzędzie, które dzia odpowiadały na aktualne potrzeby. Niektó-mowanie. Obszarów tych jest tak dużo, że trudno nie wspiera zidentyfikowanego celu, jest bez- re z tych potrzeb wynikają z odpowiedzi, któreje wszystkie wymienić. Stan dziedziny jest w ja- użyteczne. Jednak związek ten nie jest aż tak udzieliłem na poprzednie pytania.kiś sposób odzwierciedlony w corocznych ra- wyraźnie jednokierunkowy. Zauważmy, że nie- No i jeszcze jedna sprawa, którą uważam zaportach Standish Group, które podają statystyki zwykle użyteczne narzędzie, młotek, przydaje się ważną. Ze względu na rosnące znaczenie pracydotyczących udanych i nieudanych przedsięwzięć w bardzo wielu zastosowaniach, niekoniecznie grupowej i rozproszenie użytkowników, uwa-informatycznych. Dwie obserwacje w stosun- oczywistych wtedy, gdy narzędzie to powstało żam, że planując rozwój narzędzi, trzeba brać podku do tych danych są uderzające: (1) w pełni uda- po raz pierwszy. Istnieje więc jeszcze inne kryte- uwagę ich wersje „internetowe” z cienkim lubnych jest około 30% przedsięwzięć (inne mają rium oceny narzędzi, które można by nazwać pogrubionym klientem. Niewpisanie się w tenmniejsze lub większe trudności) oraz (2) pro- ich uniwersalnością, a więc zdolnością do uży- trend grozi utratą rynku lub zdecydowanymporcje te nie podlegają znaczącej zmianie wraz cia w różnych celach, niekoniecznie z góry prze- jego zawężeniem. Warto również poważnie roz-z upływem czasu. W jakiś sposób mówi to o sta- widzianych. Uważam to za bardzo ważne, gdyż ważać model biznesowy polegający na udostęp-nie inżynierii oprogramowania i wskazuje na chroni to narzędzie przed moralnym starze- nianiu usług związanych z narzędziami, a nieogrom problemów czekających rozwiązania. niem się i zwiększa jego zdolność do „przeżycia”. model zakładający sprzedaż narzędzi jako pro- Osobiście uważam, że potrzebna jest eksplo- W przeciwieństwie do narzędzi zbyt wyspecja- duktów. Ten sposób myślenia o narzędziachracja obszaru pomiędzy dwoma zauważalnymi lizowanych, które się szybko dezaktualizują. Na może okazać się bardzo trafny w kontekścietendencjami w podejściu do inżynierii opro- gruncie informatyki, ze względu na zmienność (być może) nadciągającej rewolucji związanejgramowania: z jednej strony nadawanie priory- w tej dziedzinie, istnieje wcale pokaźne „cmenta- z cloud computing.tetu metodom i narzędziom, a z drugiej ludziom rzysko” takich narzędzi.i ich profesjonalizmowi. Kierunki te w jakiś spo- Kolejny dylemat, to złożoność funkcjonalna. Janusz Górski (prof. dr hab. inż., prof. zw. PG) kieru-sób odzwierciedlają różnice pomiędzy „sztywnym” Przez analogię, czy lepiej używać młotka z koń- je Katedrą Inżynierii Oprogramowania na Politech-i „zwinnym” podejściem do wytwarzania oprogra- cówką do wyciągania gwoździ, czy też uży- nice Gdańskiej. W pierwszej połowie lat 90. utwo-mowania. Wydaje mi się, że bardzo ważna jest wać młotka „konwencjonalnego” i obcęgów? rzył pierwszą w kraju specjalizację z zakresu inżynie-głębsza eksploracja i zrozumienie obszaru, który W pierwszym wypadku mamy dwie funkcje rii oprogramowania na studiach wyższych. W dru-mieści się pomiędzy tymi skrajnościami. złożonym narzędziu, w drugim dwa narzędzia, giej połowie lat 90. utworzył pierwsze w kraju stu- Inny obszar, który mnie szczególnie interesuje, każde do realizacji jednej prostej funkcji. Zau- dium podyplomowe inżynierii oprogramowania.to rola zaufania i środki budowy zaufania w od- ważmy, że w tym wypadku odpowiedź zależy W roku 1999 był inicjatorem i pierwszym przewodni-niesieniu do procesów i produktów związanych od tego, jak wygląda proces użytkowania tych czącym Krajowej Konferencji Inżynierii Oprogramo-z oprogramowaniem. Ma to silne przełożenie na narzędzi. Bez analizy tego procesu trudno jest wania, która do chwili obecnej jest głównę platfor-takie własności poza-funkcjonalne jak bezpieczeń- dać jednoznaczną odpowiedź. Jednak z punktu mą grupującą badaczy tej tematyki w kraju. Prowa-stwo, zabezpieczenie czy prywatność. Wspólnym widzenia przyszłej ewolucji, zmian funkcji już dził i konsultował wiele projektów rozwojowych i ba-mianownikiem, który łączy te obszary, jest zarzą- istniejących lub dodawania nowych, rozwią- dawczych zarówno w kraju, jak i na forum między-dzanie ryzykiem. zanie drugie, w duchu unixowym, wydaje się narodowym, w tym również w programach ramo- Oba wymienione wyżej obszary są przedmio- mieć przewagę. Tym bardziej podkreśla to ko- wych UE (programy ENVIRONMENT, COPERNICUS,tem badań w kierowanej przeze mnie grupie ba- nieczność zadbania o to, by narzędzia mogły 5. i 6. Programy Ramowe). Jest ekspertem Komisjidawczej, która działa w Katedrze Inżynierii Opro- ze sobą współpracować. A to z kolei zwraca uwa- Europejskiej w 5. 6. i 7. Programach Ramowych. Jestgramowania Politechniki Gdańskiej. gę na standaryzację dotyczącą takiej współ- również doradcą Dyrektora European Network and pracy. I na konieczność właściwego rozumienia Security Agency (ENISA) w zakresie kierunków roz-Czy możliwe jest uporanie się z budową nowo- pojęcia „standard”. W pojęciu tym kryje się uz- woju Agencji oraz oceny wybranych obszarów ba-czesnych, skomplikowanych systemów IT bez godnienie i akceptacja, bez których „standard” dawczych. Jego obecne zainteresowania dotycząodpowiedniego warsztatu narzędzi ? standardem nie jest. Na tym tle dość chwiejne inżynierii oprogramowania (w szczególności pro-Jak w każdej innej dziedzinie, narzędzia są po- są tezy o tym, że nowo pojawiające się na ryn- blemów związanych ze skutecznym pozyskiwaniemtrzebne i mogą okazać się nadzwyczaj przydat- ku narzędzie „wprowadza standard” w dotyczą- oprogramowania przez klientów) oraz zrządzaniane. Szczególnie gdy rozpatrujemy problemy ska- cym go zakresie. Przy braku powszechnej ak- ryzykiem dotyczącym procesów i produktów pro-li, czy to w odniesieniu do złożoności, czy do ceptacji okres życia takich „standardów” jest gramistycznych. W szczególności w odniesieniu dowydajności lub kosztu. Narzędzia mogą rów- czasem zaskakująco krótki. ryzyka związanego z bezpieczeństwem, zabezpie-nież skutecznie chronić człowieka przed popeł- Uniwersalność nie pozostaje w sprzeczności czeniem i prywatnością. W kierowanym przez niegonianiem błędów i zdecydowanie zwiększają ze specjalizacją, jeżeli w architekturze narzędzia zespole (http://iag.pg.gda.pl) rozwijana jest innowa-szansę na powtarzalność rezultatów. Nie wyo- wyraźnie oddzielimy to, co uniwersalne, od tego, cyjna w skali międzynarodowej metodologia Trust-IT,brażam sobie, by skuteczne podjęcie wyzwań, co wyspecjalizowane. W części wyspecjalizowanej ukierunkowana na wspomaganie zarządzania ar-o których wspominałem wcześniej, było moż- można dopuścić do wyraźnego ukierunkowania gumentacją i wykorzystanie argumentów w budo-liwe bez wsparcia narzędziowego. Należy jed- na określoną metodę, funkcjonalność czy sprofi- wie zaufania i w innych obszarach zastosowań. Jed-nak pamiętać, że programy budują ludzie, a nie lowanie użytkowników. Rozróżnienie takie wspo- nym z takich obszarów jest wspomaganie procesówmetody i narzędzia. Oznacza to w szczególno- maga przystosowywanie narzędzia do zmian dochodzenia i oceny zgodności z normami i standar-ści, że narzędzi nie można rozpatrywać w izo- i w efekcie jego przeżywalność na rynku. dami (projekt NOR-STA, www.nor-sta.eu realizowa-lacji od używających ich ludzi oraz zadań i pro- Narzędzi, za wyjątkiem być może tych naj- ny w ramach Programu Operacyjnego Innowacyjnacesów, w które są oni zaangażowani. bardziej uniwersalnych, nie można rozpatrywać Gospodarka). 15

×