Projekty

Linki

Polecam


Ewolucja czy rewolucja?

wtorek 16 cze 2009

Cleeve Amos zamieścił poniższy obrazek w swojej prezentacji. Kolejny raz jeden obraz znaczy więcej niż setki słów.image


OpenUp

poniedziałek 19 maj 2008

Bardzo się cieszę, że po kilku latach „ukrywania” w płatnych wersji metodyki Rational Unified Process (RUP) IBM uwolnił ją publikując bezpłatną jej wersję zwaną OpenUP – Open Unified Process.

Open Unified Process (OpenUP) jest częścią szablonu procesów Eclipse’a Eclipse Process Framework (EPF) o którym pisałem kilka dni temu.

image Można powiedzieć, że proces OpenUP jest bratem procesu RUP. Z dokumentacji procesu OpenUP  można dowiedzieć się, iż opisywany proces jest iteracyjny, minimalny, kompletny i rozszerzalny. Ponadto podobnie jak w RUP w obrębie procesu występują cztery fazy:

  • rozpoczęcie (ang. inception),
  • opracowanie (ang. elaboration),
  • wytworzenie (ang. construction),
  • przekazanie (ang. transition).

W obrębie każdej fazy może występować wiele iteracji. Istotą OpenUP jest podział pracy na niewielkie iteracje, demonstrowanie wyników i ich ocena oraz otrzymywanie „sprzężenia zwrotnego” od odbiorców systemu.

W przeciwieństwie do RUP OpenUp nie wspiera modelowanie biznesowego. Więcej na temat tej metodyki można przeczytać na stronie dotyczącej Eclipse Process Framework.


Eclipse Process Framework

piątek 9 maj 2008

Jestem zwolennikiem wolnego oprogramowania i wszystkich narzędzi, które pozwalają na pracę przy podobnych standardach co narzędzia płatne. Dlaczego? W każdym działaniu liczy się człowiek i jego wiedza, doświadzcenie. Narzędzie to tylko dodatek. Dlatego też bardzo się ucieszyłem, że jest już odpowiednik IBM Rational Method Composer – narzędzia, która jest platformą pozwalajacą projektować model procesów  zgodnych z Rational Unified Process (i nie tylko). IBM Rational Method Composer  jest produktem, który umożliwia zbudowanie portalu zawierającego opis procesów, które nie są  ograniczone do sfery tworzenia oprogramowania. Tego typu rozwiązanie może być przydatne przykładowo do opisu procedur i procesów biznesowych. IBM Rational Method Composer zawiera wiele wtyczek i dodatków i jest płatny. Bezpłatnym rozwiązaniem jest, które posiada niemalże identyczną funkcjonalność jest Eclipse Process Framework (EPF). EPF pozwala także na budowanie metod i procesów, zarządzanie biblioteką metodyki, konfigurowania i co moim zdaniem jest najważniejsze publikowanie zamodelowanych wcześniej procesów.

przeczytaj pozostałą część »


Projektowanie hurtowni danych w oparciu o język UML

piątek 28 mar 2008

Nowoczesne zarządzanie organizacjami XXI wieku to sprawne i dynamiczne decyzje oparte na zebranych i dobrze przeanalizowanych danych. Coraz to większe potrzeby w zakresie analizy danych związane z wielopłaszczyznową pracą korporacji wymuszają powstawanie nowych hurtowni danych, których budowa staje się coraz bardziej złożona. Tekst ten przedstawia jedną z metodyk projektowych w zastosowaniu do projektowania hurtowni danych. Szczególny nacisk położono na transformacje jakie umożliwia zastosowanie modeli UML z udziałem Common Warehouse Metamodel.

przeczytaj pozostałą część »


Rational Unified Process – Wstęp

czwartek 8 lis 2007


Rational Unified Process jest zunifikowanym procesem wytwórczym oprogramowania dostarczającym praktycznych wskazówek, wzorców dokumentów i narzędzi, szablonów dokumentów oraz przykładów postępowania dla niemalże wszystkich działań związanych z procesem wytwarzania oprogramowania .

W swojej książce Kroll i Kruchten definiują RUP z trzech perspektyw. Pierwsza z nich określa RUP jako programową metodę ewolucyjną, która wspiera wytwarzanie oprogramowania i która jest iteracyjna, architekturocentryczna oraz jest ukierunkowana na przypadki użycia. Iteracyjność RUP oznacza ulepszanie systemu w wielu cyklach procesu. Każda iteracja kończy się uruchamialnym fragmentem kodu programu bądź systemu.

Iteracyjny proces rozwoju oprogramowania (na podstawie RUP)

Architekturocentryczność RUP oznacza, że wybór architektury oprogramowania ma istotne znaczenie dla procesu tworzenia oprogramowania. a ukierunkowanie na przypadki użycia określa funkcjonalność systemu, która powinna być zgodna z wymaganiami na system.

Drugie ujecie RUP mówi o dobrze zdefiniowanym i dobrze ustrukturalizowanym środowisku wspierającym procesy wytwórcze oprogramowania. Środowisko wytwarzające oprogramowanie określone jest w dwóch wielkościach: statycznej i dynamicznej. Zagadnienie to szczegółowo jest opisane w podrozdziale .

Trzecia definicja RUP opisuje go jako konfigurowalne środowisko do wytwarzania oprogramowania. Oznacza to, że RUP nadaje się do zastosowania w każdej organizacji wytwarzającej oprogramowanie. Dobrze spełnia swoją rolę zarówno przy małych projektach, gdzie pracuje od 3 do 10 programistów a proces wytwarzania jest krótszy niż rok, jaki i do dużych projektów. Metodyka RUP jest tak skonstruowana, że w zależności od potrzeb można skorzystać z tylko tych procesów, które uważamy w danej chwili za najlepsze i najbardziej pomocne.

Metodyka RUP stanowi swoisty przewodnik jak stosować Unified Modeling Language (UML) i jest wsparta przez całą rodzinę narzędzi CASE.

Ważnym aspektem jest fakt, że czynności wchodzące w skład RUP polegają na tworzeniu i pielęgnowaniu modeli a nie dokumentów papierowych .


Rational Software Architect Pierwszy Krok

piątek 28 wrz 2007

W artykule zaprezentowano jak rozpocząć pracę z

i opis elementów tego narzędzia CASE.

Środowisko IBM Software Development Platform (SDP) o nazwie kodowej „Atlantic”, tworzy platformę współpracy dla zespołów deweloperskich w ramach środowiska Eclipse oraz pozwalają łączyć funkcje biznesowe, rozwojowe i operacyjne w ramach organizacji. Jednym ze składników SDP jest IBM Rational Software Architect (RSA) – zintegrowane narzędzie projektowe i programistyczne, które umożliwia wykorzystanie techniki programowania modelowego w języku UML do opracowywania dobrze zaprojektowanych aplikacji i usług.

Co to jest Rational Software Architect?

IBM Rational Software Architect jest nowoczesnym pełnym środowiskiem rozwoju aplikacji, które umożliwia projektowanie w języku UML 2.0 aplikacji oraz jej implementację. RSA jest to zbiór szeregu narzędzi (Rysunek 1), wspierających procesy wytwórcze systemów informatycznych.


Rysunek 1 Komponenty IBM Rational Software Architect’a

Każdy z przedstawionych komponentów RSA wspiera twórców oprogramowania w określonej dziedzinie.

Software Modeler to narzędzie do wizualnego modelowania i projektowania aplikacji, które pozwala efektywnie wykorzystywać standard UML 2.0, do komunikowania i dokumentowania tworzonych rozwiązań. Wspomaga analizę i projektowanie.

Web Developer jest przeznaczony dla twórców aplikacji web, zorientowanych na tworzenie dynamicznych stron WWW, Web Services. Web Developer jest łatwym w użyciu wizualnym narzędziem, które efektywnie utylizuje standardy JSF, EGL.

IBM Rational Application Developer for WebSphere Software stanowi wszechstronne, zintegrowane środowisko programowania (IDE), które pozwala szybko projektować, tworzyć, analizować, testować, profilować i wdrażać aplikacje internetowe i portalowe, aplikacje w technologii Java i J2EE oraz aplikacje wykorzystujące Web Services.

Zaprezentowana krótka charakterystyka komponentów składowych RSA pozwala pozycjonuje to narzędzie w grupie zaawansowanych produktów deweloperskich.

Instalacja

Instalację Rational Software Architect?a należy zacząć od sprawdzenia czy maszyna, na której chcemy zainstalować to środowisko projektowo programistyczne podoła wymaganiom sprzętowym i programowym. RSA wymaga minimalnie:
- procesora Intel(TM) Pentium(R) III 800 MHz (zalecany jest większy)
- pamięci RAM 768 MB (zalecany jest więcej)
- 3 GB wolnego miejsca na dysku twardym

Są to dość duże wymagania zwłaszcza odnośnie pamięci RAM i może być odrobinę kłopotliwe dla posiadaczy trochę starszych komputerów.

Jeśli chodzi o system operacyjny to ucieszą się zapewne miłośnicy Linuksa, gdyż RSA jest dostępny zarówno na platformę Windows jak i Linux. W artykule tym opisane zostanie instalacja w środowisku Windows. Tyle tytułem wstępu.

Zanim zaczniemy instalację musimy posiadać minimum 2 pliki. Pierwszy z nich jest programem rozpakowującym (extractor.exe), a drugim jest plik z rozszerzeniem .blin (*.bin), który zawiera pliki RSA (core installation files). W opcji można zainstalować także: Rational Software Architect Language Pack, Enterprise Generation Language (EGL), WebSphere Application Server V6.0 Test Environment, Agent Controller, WebSphere Portal Runtime Environment.

Program instalacyjny uruchamiany jest w dwóch etapach. W pierwszym uruchamiane jest program inicjujący instalację (rozpakuje pliki z RSA i opcjonalne komponenty). Drugi etap to właściwa instalacji Rational Software Architect?a. W czasie instalacji należy wybrać komponenty, które chcemy zainstalować (Rysunek 2). Instalacja RSA przebiega bez większych trudności, choć czasem komputer może sprawiać wrażenie, że się ?zawiesił?.


Rysunek 2. Wybór komponentów podczas instalacji RSA

Uruchomienie środowiska

Podczas uruchomienia Rational Software Architect’a proszeni jesteśmy o określenie katalogu (workspace). W którym przechowywane będą projekty. (rys 2)

Rysunek 3. Projekty w RSA

Rational Software Architect oferuje szereg szablonów projektowych. W zależności od potrzeb można projektować w UML, budować rozwiązania w Java, EJB, J2EE, C, C++. Z racji tego, że RSA jest bazuje na środowisku Eclipse i języku Java to umożliwia budowę rozwiązań uniezależnionych od platformy w tym pozwala na budowę szeregu aplikacji dedykowanych do pracy w środowisku Internet.

Rysunek 4. Projekty w RSA

Każdy wybór projektu uruchamia odpowiedni kreator projektu, podczas pracy którego należy podać nazwę projektu, określić miejsce położenia projektu (jeśli jest inne niż domyślna przestrzeń). W tak zdefiniowanym projekcie można już budować system.

Rational Software Architect, zwłaszcza początkującego twórcę systemów informatycznych, może przytłoczyć nadmiarem obszarów(Rysunek 5). Początkowy chaos widoków w miarę poznania środowiska przekształca się w miarę uporządkowany zestaw pomocnych informacji, z których w zależności od wymagań i upodobań można korzystać lub nie.

Rysunek 5. Widok projektu w RSA

W poniższej tabeli bardzo skrótowo omówiono znaczenie najważniejszych okien (dla porządku otrzymały one kolejne numery)

numer okna

opis

zdjęcie

1

Navigator- stanowi repozytorium artefaktów projektu. Można w nim stosować takie elementy jak klasy, foldery, pliki. Jest to główny element nawigacji projektem. Dodatkowo uwidacznia (elementy z krzyżykiem), które są niepoprawne

2

Edytor kodu jest miejscem, które służy do wpisywania kodu źródłowego aplikacji. Kolorowanie składni oraz podświetlanie błędów w składni programu to jego niewątpliwe zalety.

3

Właściwości (Properties) zawiera informacje o pliku, w którym istnieje edytowana klasa.

4

Konsola (Console) zawiera informacje o kompilacji programu lub o jego działaniu

5

Eksplorer pakietów (Package Explorer) zawiera informacje o umiejscowieniu klas i metod w konkretnych plikach

6

Problem ? obszar odpowiedzialny za wyświetlanie informacji o występujących błędach lub problemach z budowana aplikacją.

W tabeli 1 umieszczono najważniejsze widoki z jakich korzystać może użytkownik RSA.

Narzędzie uruchomione. W kolejnym artykule zostanie przedstawiony sposób projektowania w RSA


Artykuł napisano w 2005 roku. Od tego czasu wiedza i narzędzia mogły ulec zmianie. :)


Cykl tworzenia oprogramowania w Rational Unified Process

wtorek 31 lip 2007

Procesy, jakie są realizowane w czasie budowy oprogramowania, są zazwyczaj cykliczne. Systemy, w zależności od zastosowanej metody, charakteryzują się spiralnym, kaskadowym (wodospadowym) lub strukturalnym cyklem wytwarzania. Praktycznie każda metodyka preferuje swój cykl wytwórczy.

Cykl wytwórczy RUP jest charakterystyczny, gdyż pokazuje procesy w dwóch płaszczyznach. W pionie przedstawione są statyczne aspekty wytwarzania oprogramowania, takie jak czynności, role, przepływy oraz artefakty jakie im towarzyszą. W poziomie natomiast przedstawione zostały dynamiczne aspekty wytwarzania oprogramowania takie, jak fazy oraz iteracje.


Cykl tworzenia oprogramowania w RUP (na podstawie RUP)

Fazy tworzenia oprogramowania

RUP składa się z czterech faz wytwórczych oprogramowania. Pierwsza faza to Rozpoczęcie (ang. Inception), która jest odpowiedzialna za określenie założeń przedsięwzięcia. Ustala się w niej założenia techniczne, rynkowe i ekonomiczne. Na etapie tym tworzony jest harmonogram prac oraz szacuje się ryzyko powodzenia projektu. Pod koniec fazy rozpoczęcia następuje określenie celów przedsięwzięcia oraz zapada decyzja czy nastąpi przystąpienie do pełnego procesu wytwórczego.

Gdy zapada decyzja o kontynuacji, projekt przechodzi w fazę Opracowania (ang. Elaboration). Etap ten polega na analizie dziedziny problemu, solidnym zdefiniowaniu architektury, przygotowaniu planu prac i zneutralizowaniu największych zagrożeń . Wszystkie wymienione powyżej czynności mogą zaistnieć tylko w sytuacji, gdy opisano większość wymagań na system.

Kolejną fazą jest Budowa (ang. Construction). Podczas tej fazy w sposób iteracyjny i przyrostowy następuje budowanie oraz integrowanie wszystkich komponentów składających się na tworzony system. Końcowym produktem tej fazy jest gotowy, w pełni przetestowany oraz udokumentowany program nadający się do wdrożenia.

Ostatnią fazą procesu wytwórczego RUP jest Przekazanie (ang. Transition). Celem tego etapu jest przekazanie użytkownikowi końcowemu gotowego systemu. W fazie Przekazania na światło dzienne wychodzą nieprzewidziane do tej pory problemy z systemem, które wymagają często dodatkowych prac programistycznych. Po tych czynnościach mających na celu dopracowanie rozwiązania może nastąpić produkcja systemu, która kończy proces wytwarzania oprogramowania.

Wymienione powyżej fazy składają się z iteracji, czyli działań produkcyjnych zmierzających do stworzenia funkcjonalnej części systemu. Przejście przez wszystkie fazy stanowi cykl wytworzenia oprogramowania. Każde przejście przez wymienione fazy daje nową generację oprogramowania.

Planowanie faz

Fazy składające się na proces wytwórczy oprogramowania nie rozkładają się równomiernie ani pod względem czasochłonności, ani pod względem potrzebnych do ich realizacji zasobów. Lata doświadczeń metodyków wykazały, że w czasie projektowania systemów na realizację poszczególnych faz należy zarezerwować odpowiednią ilość czasu. W swoim artykule David West określa, że na fazę Rozpoczęcia należy przeznaczyć 10% czasu projektu. Faza Opracowania wymaga 30% czasu. Najwięcej czasu potrzeba na fazę Budowy, bo aż około 50%. Ostanie 10% procent należy przeznaczyć na fazę Przekazania. Odmiennie od rozkładu czasu wygląda rozkład potrzebnych zasobów do realizacji faz. I tak faza Rozpoczęcia wymaga użycia około 5% zasobów. Etap opracowania pochłania zazwyczaj około 20% środków. Najbardziej zasobożerny jest etap budowy, który na swoje potrzeby zużywa około 65% zasobów. Na ostatnią fazę Przekazania zostaje około 10% środków.


Zasoby i czas potrzebny do realizacji cyklu oprogramowania (na podstawie RUP)

Przedstawione liczby są tylko orientacyjnymi danymi, gdyż każdy projekt z racji swej niepowtarzalności może mieć inny rozkład faz w czasie i wymagać dla każdego etapu innych zasobów.


Najczęściej czytane

Kategorie

  • agile
  • architektura korporacyjna
  • Enterprise Architect
  • literatura
  • metodyki
  • modelowanie biznesowe
  • o inżynierii oprogramowania
  • ogólne
  • SCRUM
  • StarUML
  • szkolenia
  • teksty
  • WMB
  • wydarzenia
  • zarządzanie wymaganiami
  • zwinne modelowanie
  • Słowa kluczowe

    agile agile modeling aktor biznesowy aplikacje webowe ASP.NET biznesowy przypadek użycia byt biznesowy diagram aktywności diagramy Enterprise Architect Extreme Programming IBM Rational Software Modeler inżynieria oprogramowania konsultacje metoda punktów przypadków użycia metodyki wytwarzania oprogramowania model analizy biznesowej model biznesowych przypadków użycia modelowanie modelowanie biznesowe modelowanie procesów biznesowych modelowanie systemów informatycznych narzędzia CASE pracownik biznesowy proces wytwórczy oprogramowania procesy biznesowe projektowanie systemów informatycznych przypadki użycia Rational Software Architect Rational Unified Process RUP scenariusze procesów biznesowych SCRUM Service Oriented Architecture SOA StarUML szacowanie oprogramowania szkolenie testowanie UML Unified Modeling Language wymagania na system XP zarządzanie wymaganiami zwinne modelowanie

    Archiwum