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 Enterprise Architect, o inżynierii oprogramowania
środa 13 maj 2009
Szacowanie projektu oraz jego złożoności jest trudne. Istnieją metody, które wspomagają ten proces. Jedną z nich jest metoda use case points. O samej metodzie nie będę pisał bo wiele jest o niej informacji w Internecie. Natomiast warto wiedzieć, że Enterprise Architect wspomaga to szacowanie. Wystarczy przy każdym przypadku użycia określić parametr Complexity (patrz własności PU) i gotowe. Potem można przystąpić do szacowania?
przeczytaj pozostałą część »
napisane przez Michał Wolski | w kategorii agile, szkolenia, wydarzenia
poniedziałek 11 maj 2009
W dniach 7-8 maja prowadziłem w Warszawie szkolenie z projektowania systemów informatycznych. Nikt z uczestników szkolenia nie miał wątpliwości, że modele w UML są przydatne a jednocześnie metodyki z nurtu Agile odrzucają modelowanie. Oczekiwania wobec szkolenia krążyły wobec tematów co i jak dokumentować w UML? Jak obszerną dokumentację wykonywać? Jak połączyć modelowanie w UML z zwinnymi (ang. Agile) metodykami takimi jak XP czy Scrum. W trakcie szkolenia zaprezentowałem istotę metodyk zwinnych i ciężkich oraz zaprezentowałem klucz - łącznik pozwalający na połączenie modeli wyrażonych w UML z zwinnym podejściem. Wskazałem także jak zaprezentowane rozwiązanie może dodatkowo pozwolić na lepsze wymiarowanie projektu np.: w zakresie ustalenia zakresu iteracji ? sprintu jak to mówią wyznawcy Scrum.
Wydaje mi się, że szkolenie spełniło oczekiwania jego uczestników o czym świadczą ankiety: w zakresie sposobu prezentacji tematu, przydatności szkolenia i mojego przygotowania otrzymałem same dobre i bardzo dobre oceny. Dziękuję szczególnie za jedną opinię w punkcie: ?Co się Państwu najbardziej podobało w niniejszych warsztatach??, która brzmi ?Kompetencja prowadzącego i sposób prowadzenia szkolenia?. 
napisane przez Michał Wolski | w kategorii o inżynierii oprogramowania, wydarzenia
czwartek 26 mar 2009
Od kilku dni jest dostępne wiosenne wydanie The Rational Edge.
http://www.ibm.com/developerworks/rational/rationaledge/?S_TACT=105AGX15&S_CMP=EDGE
Jak zwykle garść dość ciekawych artykułów. Tym razem wydanie zostało poświęcone szacowaniu projektów. Wskazuje na to artykuł Colin O’Neill?a, w którym można znaleźć kompletne wzory i techniki pozwalające wyliczyć ROI projektu oraz (bardziej mnie) interesujący tekst dotyczący szacowania złożoności oprogramowania w oparciu o punkty funkcyjne. Wyliczanie złożoności i kosztów w oparciu o punkty funkcyjne jest o tyle istotne, że ROI jest złudne, o czym warto pamiętać. Ponadto czasem buduje się soft z ROI bliskim zera lub ujemnym co wynika np.: z wymogów prawa. Natomiast szacowanie oprogramowania w oparciu o punkty funkcyjne przypadków użycia pozwala na oszacowania nie tylko kosztów ale także złożoności. Może to być także klucz do planu iteracji. Po trzecie ja ten artykuł zaciekawił mnie szczególnie bo sam używam tej metody.
Nie mniej jednak oba teksty będą na pewno przydatne wszystkim osobom, które w ?jakiś magiczny sposób? muszą oszacować oprogramowanie pod względem opłacalności.
