Category Archives szacowanie oprogramowania

Planując pracę  swoją czy też swojego zespołu staram się przestrzegać kilku zasad. Oto one:

Plan szczegółowy buduję jedynie dla najbliższych zadań. Moim zadaniem użyteczne są plany na kilka najbliższych dni, tygodni, ale nie na kilka najbliższych miesięcy.

Nie przepadam za wykresami Gantta. Coraz częściej dochodzę do wniosku, że wykresy Gantta mają małą wartość dla projektów agile. Pomagają mi przemyśleć główne zależności ale nic więcej. Najlepszą techniką jest dla mnie się lista zadań dotyczących iteracji.

Zawsze staram się planować z zespołem. To ważne by ludzie wykonujący pracę byli aktywnie zaangażowani w planowanie. Są oni wtedy bardziej zmotywowani, aby wykonać swoją pracę dobrze. Ponadto jako współtwórcy planu prac łatwiej go akceptują.

W trakcie prac projektowych lub analitycznych wielokrotnie powstaje potrzeba policzenia parametrów procesu biznesowego lub szacowania złożoności budowanego oprogramowania.  Większość metod formalnych wymaga bardzo często dość trudnych obliczeń. Z drugiej strony w trakcie prac analitycznych lub projektowych powstaje zazwyczaj diagram aktywności, który w sposób naturalny prezentuje składowe procesu biznesowego lub elementy scenariusza przypadku użycia. W artykule tym postaram się zaprezentować jak za pomocą diagramów aktywności zamodelowanych w Enterprise Architect i dodatkowego narzędzia (Tormigo) można policzyć wybrane parametry procesu biznesowego.

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.

clip_image002

Rysunek 1. Przeglądarka projektu narzędzia Enterprise Architect i widoczne elementy modelu systemu oceny pracowników: aktorzy systemu i przypadki użycia.

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.

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.

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.

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?

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…

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…

Close