www.eprace.edu.pl » iso-cmm » CMM » Użycie CMM

Użycie CMM

CMM ustala zestaw publicznie dostępnych kryteriów opisujących cechy charakterystyczne dojrzałych organizacji software’owych. Te kryteria mogą być używane przez organizacje do udoskonalania ich procesów, rozwoju i utrzymywania oprogramowania albo przez rząd i organizacje handlowe do szacowania ryzyka przystąpienia do kontraktu na dany projekt oprogramowania z daną firmą.

Ten rozdział koncentruje się na dwóch rozwiniętych przez SEI metodach oceny dojrzałości przeprowadzania procesów tworzenia oprogramowania przez organizację. Są to: Szacowanie Procesu Tworzenia Oprogramowania (Software Process Assessments) i Ocena Potencjału Oprogramowania (Software Capability Evaluation).

Jeśli Czytelnik chciałby samodzielnie przeprowadzić taką ocenę czy szacowanie, powinien poszukać dodatkowych informacji, gdyż szczegółowy opis tych zagadnień wykracza poza ramy tego opracowania.

CMM jest ogólną podstawą zarówno dla Szacowania Procesu Tworzenia Oprogramowania, jak i dla Oceny Potencjału Oprogramowania. Cele metod są całkiem różne i istnieją znaczące różnice pomiędzy tymi metodami. Obydwie opierają się na modelu i produktach od niego pochodzących. Model CMM łącznie z produktami na nim opartymi umożliwia stosowanie powyższych metod w sposób niezawodny i konsystentny.

Metody Szacowania Procesu i Oceny Potencjału.

Szacowanie Procesu Tworzenia Oprogramowania koncentruje się na identyfikowaniu priorytetów w obrębie procesu tworzenia oprogramowania. Zespoły oceniające stosują model CMM, aby pomagał zidentyfikować i uszeregować wyniki badań. Na podstawie tych wyników zespoły inżynierii procesu tworzenia oprogramowania planują strategię udoskonalania w organizacji.

Ocena Potencjału Oprogramowania identyfikuje ryzyko wykonywania wysokiej jakości oprogramowana w terminie i mieszcząc się w kosztach, które są związane z danym projektem czy kontraktem. Wnioski tej oceny mogą posłużyć do wyznaczenia ryzyka przy wybieraniu szczególnego kontrahenta. Ocena ta może być również stosowana wobec istniejących kontrahentów, w celu monitorowania wykonania procesów i wyznaczania potencjalnych możliwości poprawy procesu tworzenia oprogramowania.

Model CMM stanowi ogólną konstrukcję do przeprowadzenia oszacowania procesu tworzenia oprogramowania i oceny potencjału procesu. Chociaż metody te różnią się w zamierzeniach, używają jednak modelu CMM jako fundamentu do oceny dojrzałości procesu tworzenia oprogramowania. Rysunek 3.8 dostarcza pobieżnego opisu normalnych kroków przy ocenie i szacowaniu.

R
ysunek 3.8.
Normalne kroki przy szacowaniu i ocenie potencjału procesu

Pierwszym krokiem jest wybranie zespołu. Zespół ten powinien być zaznajomiony z podstawowymi pojęciami modelu CMM, jak również ze specyfiką metod szacowania i wyceny. Członkowie zespołu powinni dobrze orientować się w inżynierii oprogramowania i zarządzaniu.

Drugim krokiem jest wyznaczenie reprezentantów ze strony badanej, skompletowanie kwestionariuszy dojrzałości i innych narzędzi diagnostycznych. Jeśli te czynności są skończone, zespoły szacujące i oceniające wykonują analizę odpowiedzi (krok 3); tutaj rozpatruje się problemy i wyznacza obszary, które mają być poddane dalszemu badaniu. Te obszary wyznaczone do dalszego badania odpowiadają obszarom procesów kluczowych CMM.

Następnie zespół może już złożyć wizytę w badanym miejscu (krok 4). Zaczynając od wyników analizy odpowiedzi, zespół przeprowadza rozmowy (interviews) i wykonuje przeglądy dokumentacji, aby w pełni zrozumieć proces tworzenia oprogramowania, który prowadzony jest przez stronę badaną. Przez cały czas prowadzenia rozmowy, zbierania odpowiedzi, wykonywania przeglądów i syntezy informacji otrzymanej z przesłuchań i dokumentów członkowie zespołu kierują się obszarami procesów kluczowych i praktykami kluczowymi. Zespół wydaje profesjonalną opinię decydując, czy badana strona odpowiednio zaimplementowała obszary procesów kluczowych spełniając odpowiednie cele obszarów procesów kluczowych. Jeśli istnieją znaczące różnice pomiędzy praktykami kluczowymi CMM i praktykami strony badanej, zespół musi udokumentować racjonalne podstawy ku temu, aby uznać ten obszar procesów kluczowych.

Pod koniec okresu “u strony badanej”, zespół wykonuje listę wyników badań (krok 5). Lista ta zawiera silne i słabe strony procesu tworzenia oprogramowania organizacji. Przy ocenie procesu tworzenia oprogramowania (software process assessment) te wyniki badań są postawą do rekomendacji (zaleceń) poprawy procesu tworzenia oprogramowania. Przy szacowaniu potencjału (software capacity evaluation), wyniki te stanowią część analizy ryzyka przeprowadzanej przez agencje akwizycyjne.

Ostatecznie, zespół przygotowuje profil obszaru kluczowego (krok 6), który pokazuje, gdzie organizacja dobrze spełniła cele obszarów procesów kluczowych, a gdzie ich nie spełniła.

Podsumowując, obydwie metody: ocena procesu tworzenia oprogramowania i szacowanie potencjału:

Różnice pomiędzy szacowaniem procesu tworzenia oprogramowania i oceną jego potencjału.

Pomimo tych podobieństw, wyniki szacowania procesu i oceny jego potencjału mogą być nieco inne. Jednym z powodów jest to, że zakresy oceny i szacowania mogą się różnić. Po pierwsze, musi zostać określona sama organizacja, którą rozpatrujemy. W dużej firmie możliwe są różne definicje ”organizacji”. Dziedzina może opierać się na lokalizacji geograficznej, profilu działalności i wielu innych względach. Po drugie, w obrębie organizacji poszczególne projekty mogą również oddziaływać na wynik. Podział w obrębie organizacji może być wyznaczany przez specjalne zespoły, następnie w obrębie poszczególnych jednostek (w węższym zakresie) oceniane są poszczególne linie produkcyjne. Porównanie pomiędzy wynikami bez zrozumienia kontekstu byłoby problematyczne.

Te dwie metody różnią się pomiędzy sobą motywacja, wynikami i celami. Te składniki prowadzą do różnic w zbieraniu informacji, zakresie zapytań i formułowaniu wyników. W szczegółach metody te różnią się znacznie.

Ocena procesu tworzenia oprogramowania jest przeprowadzana w publicznym współpracującym środowisku. Jej sukces zależy od zaangażowania zarówno ze strony kierownictwa, jak i personelu zawodowego. Celem jest zajęcie się problemami i pomoc managerom i inżynierom w poprawie organizacji.



komentarze

Copyright © 2008-2010 EPrace oraz autorzy prac.