napisane przez Michał Wolski | w kategorii Enterprise Architect, o inżynierii oprogramowania, teksty
piątek 2 paź 2009
Warto wiedzieć, że istnieją na rynku narzędzia CASE, które wspierają inżynierów oprogramowania nie tylko w zarządzaniu wymaganiami, modelowaniu, projektowaniu systemów informatycznych, generowaniu kodu aplikacji, ale również w szacowaniu pracochłonności ich wytworzenia. Jednym z nich jest Enterprise Architect firmy Sparx System, który wspiera estymację pracochłonności wykonania sytemu informatycznego metodą punktów przypadków użycia.
W celu skorzystania z funkcjonalności związanej z szacowaniem pracochłonności, należy podczas tworzenia modelu systemu informatycznego konsekwentnie definiować istotne z punktu widzenia metody punktów przypadków użycia parametry wybranych komponentów, z których składa się model oraz zdefiniowania odpowiednich wartości parametrów dla tej metody.
Rysunek 1. Przeglądarka projektu narzędzia Enterprise Architect i widoczne elementy modelu systemu oceny pracowników: aktorzy systemu i przypadki użycia.
przeczytaj pozostałą część »
napisane przez Michał Wolski | w kategorii Enterprise Architect, o inżynierii oprogramowania, teksty
piątek 2 paź 2009
W tekście Szacowanie projektu w Enterprise Architect cz. 1 zdefiniowałem czynniki złożoności technicznej i środowiskowej. Teraz należy doprecyzować pozostałe parametry.
Po pierwsze możemy ustawić wartość dla parametru zwanego współczynnikiem produktywności PF (ang. Productivity Factor). Pamiętamy, współczynnik produktywności przekształca nam jeden punkt przypadku użycia na ilość godzin pracy człowieka, autor metody UCP proponował wartość tego parametru na poziomie 20. W narzędziu Enterprise Architect na zakładce Default Hour Rate okna Estimation factors (patrz rysunek 1) wartość tą wprowadza się do pola nazwanego Duration.
przeczytaj pozostałą część »
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty
czwartek 1 paź 2009
Metoda punktów przypadków użycia (ang. Use Case Points ) w skrócie UCP posiada podobny mechanizm do tego jaki zastosowano w metodzie punktów funkcyjnych (Metoda punktów funkcyjnych), jednak zrezygnowano z wykorzystania ekranów i architektury. Dlaczego pominięto ekrany i architekturę? Otóż wyobraźmy sobie sytuację, w której klient zadaje pytanie o czas realizacji projektu na etapie specyfikowania wymagań. Jak się okazuje w tej sytuacji metoda punktów funkcyjnych jest nieużyteczna, gdyż nie posiadamy jeszcze zdefiniowanej architektury, czy też propozycji ekranów. Należy więc zastanowić się czy wymagania systemu mogą być podstawą do estymacji pracochłonności realizacji systemu informatycznego. Twierdząco na tak postawione pytanie odpowiedział w 1993r. Gustaw Karner – twórca metody punktów przypadków użycia. Wymienił on architekturę i ekrany na specyfikację wymagań zapisaną w postaci specyfikacji przypadków użycia. Ponadto zasugerował, że należy zwrócić uwagę na tak zwane czynniki złożoności środowiska opisujące w dużej mierze organizację, która wytwarza oprogramowanie, czynniki złożoności technicznej opisujące własności produktu oraz przyszłych aktorów systemu.
przeczytaj pozostałą część »
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty
czwartek 1 paź 2009
Początki Use Case Points sięgają innej znanej metody służącej do szacowania rozmiaru oprogramowania, a mianowicie metody punktów funkcyjnych. Metoda ta zaproponowana przez Allana Albrechta (IBM) w 1979 bazowała na projektach ekranów oraz architekturze systemu. Była to próba przezwyciężenia problemów związanych z użyciem liczby linii kodu (która nie jest znana na etapie definicji wymagań a była podstawą do estymacji) jako miary wielkości oprogramowania i jednocześnie próba opracowania metody przewidzenia wysiłku związanego z produkcją oprogramowania. W metodzie tej występowało pięć głównych klas atrybutów produktywności, które charakteryzowały system:
- zewnętrzne wejścia (ang. External Inputs)
- zewnętrzne wyjścia (ang. External Outputs)
- zewnętrzne zapytania (ang. External Inquires)
- pliki wewnętrzne (ang. Internal Logical Files)
- pliki zewnętrzne (ang. External Interface Files)
Dla każdej kategorii zdefiniowane były trzy stopnie złożoności: prosty, średni i złożony. Z kolei z każdym stopniem złożoności były związane ustalone wartości wag.
przeczytaj pozostałą część »
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty, zwinne modelowanie
poniedziałek 28 wrz 2009
Z racji tego, że publikacja odnośnie zwinnego podejścia w zakresie modelowania procesów biznesowych (WMB) –pisałem o tym kilka dni temu w tekście pt “Krajowa Konferencja Inżynierii Oprogramowania“- ukazała się w limitowanej edycji 150 egzemplarzy pozwalam sobie na publikację skanu tego tekstu.
napisane przez Michał Wolski | w kategorii teksty, zarządzanie wymaganiami
piątek 26 cze 2009
Jakiś czas temu na stronie Pana Kowalczykiewicza http://www.cs.put.poznan.pl/kkowalczykiewicz/ był ciekawy tekst na temat dobrych praktyk w inżynierii wymagań. Obecnie ta strona jest wyłączona. Z tego też powodu pozwalam sobie na publikację tego tekstu, który (co mnie zadziwia) miałem w swoim archiwum. Tekst ten został odrobinę przeformatowany.
Ian Sommerville i Pete Sawyer zaproponowali ciekawą metodę oceny i doskonalenia procesów inżynierii wymagań. Opiera się ona na wyodrębnieniu dobrych praktyk, czyli czynności będących pożądanymi elementami wzorcowego procesu inżynierii wymagań. Autorzy starali się przy tym objąć całość problematyki inżynierii wymagań. Dobre praktyki reprezentują więc następujące obszary działalności:
- dokument specyfikacji wymagań,
- pozyskiwanie wymagań,
- analiza i negocjacja wymagań,
- opisywanie wymagań,
- modelowanie systemu,
- weryfikacja wymagań,
- zarządzanie wymaganiami,
- systemy krytyczne.
Biorąc pod uwagę te kryteria wyodrębniony został podział praktyk na trzy grupy wg zaawansowania powiązanego z tymi kosztami i poziomem skomplikowania:
Dobre praktyki stanowią podstawę do oceny poziomu dojrzałości procesów inżynierii wymagań w organizacji. Zakres wspomnianych dobrych praktyk opisałem w poniższych punktach:
napisane przez Michał Wolski | w kategorii SCRUM, agile, ogólne, teksty, zwinne modelowanie
niedziela 21 cze 2009
Każdy sprint kończy się Spotkaniem Przeglądowym Sprintu (ang. Sprint Review Meeting), gdzie zespół pokazuje potencjalnie wykonalne przyrosty produktu.
Na końcu każdego sprintu odbywa się Spotkanie Przeglądowe Sprintu. W trakcie spotkania Zespół Scrum pokazuje, co osiągnął podczas sprintu. Na ogół przybiera to formę demonstracji nowych cech. Uczestnicy Przeglądu Sprintu to zazwyczaj Właściciel Produktu, Zespół Scrum, Mistrz Scrum, kierownictwo, klienci a także inżynierowie z innych projektów. Podczas przeglądu sprintu ocenia się projekt względem celu sprintu ustalonego na Spotkaniu dot. Planowania Sprintu. Sytuacją pożądaną jest, aby zespół wykonał każdą pozycję Product Backloga przeniesioną do sprintu, ale ważniejsze jest, aby osiągnąć ogólny cel sprintu.
Spotkanie przeglądowe sprintu jest celowo bardzo nieformalne, na ogół zakazuje się stosowania slajdów w PowerPoincie i daje się nie więcej niż dwie godziny czasu na przygotowanie do tego spotkania. Spotkanie przeglądowe sprintu nie powinno przerodzić się w zakłócenie uwagi czy drogę okrężną dla zespołu; powinno być ono raczej naturalnym rezultatem sprintu.
Spis treści
Role:
Czynności:
Artefakty:
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty
czwartek 7 maj 2009
Architektura zorientowana na usługi to naturalny krok ewolucyjny od podejść zorientowanych obiektowo (OO), proceduralnych oraz dano-centrycznych stosowanych we wdrażaniu rozwiązań.
Fundamentalnymi zasadami rządzącymi SOA są:
-
Wiadomości wymieniane pomiędzy uczestniczącymi systemami muszą być opisowe a nie instruktażowe, ponieważ system informatyczny świadczący usługę odpowiedzialny jest za wszelkie problemy. Komunikaty opisowe podają informacje o usłudze oraz o powiązanych z nią danych wejściowych i wyjściowych. Usługodawcy odpowiedzialni są za wskazówki; stąd też potrzeba na komunikaty instruktażowe nie istnieje.
-
Słownik oraz struktura komunikatów muszą być zrozumiałe przez wszystkie strony. To powszechne zrozumienie przez wszystkie strony wymaga ograniczenia słownictwa oraz struktury komunikatów, ale jest koniecznością dla skutecznego komunikowania.
-
Struktura komunikatu powinna być rozszerzalna.
przeczytaj pozostałą część »
napisane przez Michał Wolski | w kategorii Enterprise Architect, teksty, zarządzanie wymaganiami
poniedziałek 4 maj 2009
Enterprise Architect, moim zdaniem, nie jest najszczęśliwszym narzędziem do zarządzania wymaganiami. Nie jest też beznadziejny.
W projektach dla mnie ważne jest to jak wymagania są mapowane na konkretne przypadki użycia (PU). Pozwala to stwierdzić, które PU są bardziej złożone, wymagają większej uwagi i są ważniejsze dla klienta. Aby to stwierdzić trzeba zmapować PU z konkretnymi wymaganiami. W tym celu dodaję wymagania na diagram i łączę asocjacja z PU a jeśli diagram jest nieczytelny to związki dodaje w macierzy. Wygenerowanie macierzy…
przeczytaj pozostałą część »
napisane przez Michał Wolski | w kategorii teksty
wtorek 14 kwi 2009
SOA czyli Service Oriented Architecture a mówiąc bardziej po polsku architektura zorientowana na usługi to niewątpliwie jeden z liderów jeśli chodzi o trendy w inżynierii oprogramowania. Trudniej jest określić czym jest SOA. Ja osobiście lubię definicję jaką w w 2004 roku na łamach Computerworld określił Tomasz Kopacz “zestaw polis, praktyk i bibliotek, które pozwalają wykorzystać funkcjonalność aplikacji w taki sposób, by można było z niej korzystać jako z zestawu usług, opublikowanych tak, by poziom szczegółowości był dostosowany do potrzeb konsumenta usługi. Publikowane elementy są niezależne od implementacji i stosują pojedynczy, standardowy interfejs".
Innymi słowy SOA w dużym uproszczeniu to nic innego jak aplikacja wyposażona w odpowiedni interfejs umożliwiający dostęp do oferowanych przez nią usług przez inne elementy systemu informatycznego zgodne z góry ustalonymi standardami. Idąc dalej tym tokiem rozumowania SOA stanowi “fasadę” na aplikację, która może być obiektowa i projektowana za pomocą języka UML ze szczególnym uwzględnieniem komponentów.
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty
piątek 10 kwi 2009
Każdy czasem zastanawia się nad wyborem najlepszego narzędzia do modelowanie w UML. Moim zdaniem nie ma idealnej recepty pomagającej dokonać wyboru. Dlatego też trzeba napisać swoje wymagania odnośnie narzędzia a potem przeklikać to i owo w kilku narzędziach do modelowania. Indywidualne odczucia powinny zdecydować. Nie mniej jednak można próbować posiłkować się rankingami. Jednym z nich jest ankieta wykonana na formu uml-forum.com gdzie 10 kwietnia dla uczestników tej ankiety najlepszym narzędziem uznany został Enterprise Architect na drugim miejscu EclipseUML a na trzecim (o zgrozo) Visio. 
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, teksty
wtorek 7 kwi 2009
Jest już nowa wersja UML – 2.2. O zmianach napiszę jak ją przejrzę.
Poza stronami OMG zamieszczam poniżej linki do całej specyfikacji:
