Zarządzanie jakością. ISO 9001 w IT część 3/3
Napisany przez SQAM SP. z o.o. SP. K. dnia 2012-12-17 13:03:55. Aktualizowano 2024-04-27 09:32:44
ISO 9001 w IT. Nadzór nad wyrobem niezgodnym w procesie produkcji oprogramowania – część III.
Użyte tagi:
Zobacz także:
Zgodnie z normą ISO 9001:2000 organizacja powinna sprawować nadzór nad wyrobem niezgodnym. W IT takim wyrobem jest system informatyczny – zarówno w trakcie wytwarzania, jak i po wdrożeniu na produkcję. Niniejszy artykuł opisuje podstawowe narzędzia i techniki wspierające identyfikację oraz zarządzanie produktem niezgodnym na etapie utrzymania oprogramowania.
Dowiesz się:
- Jakie są wymagania normy ISO 9001:2000 w zakresie nadzoru nad wyrobem niezgodnym;
- Co należy uwzględnić w fazie utrzymania oprogramowania, aby zapewnić zgodność z normą.
Powinieneś wiedzieć:
- Znajomość poszczególnych faz projektu IT oraz ich podstawowych celów i założeń;
- Podstawowa wiedza z zakresu utrzymania powdrożeniowego oprogramowania.
Po zapoznaniu się z treścią artykułu, czytelnicy dowiedzą się, w jaki sposób można zaplanować prace wchodzące w zakres utrzymania systemu na produkcji, aby zapewnić zgodność procesu z wymaganiami normy ISO 9001:2000. Niniejszy artykuł jest trzecim i ostatnim z cyklu publikacji dotyczących wdrażania systemu zarządzania jakością w przemyśle informatycznym.
W poprzednich artykułach czytelnicy mogli zapoznać się z metodami zapewnienia wysokiej jakości produktu informatycznego na etapie projektowania oraz produkcji – implementacji i testowania. Przedstawione wytyczne oraz przykładowe procedury wskazywały, na co w procesie wytwarzania należy zwracać szczególną uwagę, co może być przyczyną pojawiania się różnego typu niezgodności oraz jakie czynności powinny zostać podjęte, aby wyeliminować owe niezgodności na możliwie wczesnym etapie i uzyskać wysoką jakość oprogramowania. Jakość postrzegana przez użytkownika końcowego to zgodność ze specyfikacją i celem oraz zdolność zaspokojenia określonych potrzeb – na przykład prostota obsługi i intuicyjność rozwiązania, ergonomia itp.
Wysoka jakość oprogramowania oznacza również spełnienie wymagań nie wyrażonych bezpośrednio, lecz mimo to koniecznych dla zapewnienia prawidłowego funkcjonowania i bezpieczeństwa systemu – takich jak wymagania prawne, dotyczące ochrony danych osobowych, gromadzenia danych archiwalnych czy zapisów z wykonanych transakcji, zgodności z charakterystykami lokalizacyjnymi (np. formatowanie dat, liczb, waluty). Jakość produktów końcowych projektu informatycznego jest kształtowana przez jakość poszczególnych etapów realizacji projektu wyrażaną jako zgodność z jakością projektowaną, stopień kontroli nieprawidłowości i odchyleń oraz środków korygujących podejmowanych w reakcji na zaistniałe problemy. Może się jednak zdarzyć, iż pomimo różnorodnych środków zapobiegawczych stosowanych przez producenta podczas procesu wytwórczego, finalny produkt dostarczony klientowi nie spełnia wszystkich wymagań użytkownika. Po wdrożeniu na produkcję często okazuje się, iż pojawiają się błędy nie wykryte lub nie występujące w środowisku wytwórczym lub też uwarunkowania zewnętrzne wymuszają konieczność wprowadzania zmian do zatwierdzonego wcześniej projektu. Dostawca oprogramowania w większości wypadków (jeśli kontrakt z klientem obejmuje usługi utrzymania systemu) jest zobowiązany do usunięcia niezgodności w określonym terminie.
PRZYCZYNY NIEZGODNOŚCI W SYSTEMACH PRODUKCYJNYCH.
Niezgodności zidentyfikowane przez użytkowników podczas działania systemu na produkcji obejmują generalnie trzy rodzaje zgłoszeń:
1. BŁĘDY – defekty i usterki w działaniu systemu, odstępstwa od specyfikacji niewykryte podczas testów wewnętrznych; defekty takie mają źródło albo w nieodpowiedniej jakości procesu testowego, skutkującej pomijaniem pewnych obszarów aplikacji i “przepuszczaniem” błędów, albo w fakcie występowania danych incydentów tylko w środowisku produkcyjnym.
2. ZMIANY - nieprawidłowości w działaniu systemu (zwykle typu biznesowego) wynikające z uwarunkowań zewnętrznych – np. zmiana ustawy, przepisów lub wewnętrznych – zmiana w uprzednio zaakceptowanych wymaganiach klienta, wynikająca np. z obserwacji użytkowników końcowych pracujących z systemem w warunkach naturalnych; zmiany nie są błędami – choć zdarzają się sytuacje, w których klient zgłasza zmianę jako raport błędu – lecz modyfikacjami wykonywanymi w dotychczas działającym zgodnie z oryginalną specyfikacją systemie.
3. NOWE FUNKCJONALNOŚCI – zgłoszenia klienta mogą dotyczyć wprowadzenia do systemu nowych funkcji czy całych modułów; niezależnie od tego, czy planowana jest kolejna faza projektu mająca na celu dostarczenie zestawu następnych funkcjonalności, klient może praktycznie w każdej chwili zażądać implementacji i wdrożenia nowych opcji, jeśli istnieje taka potrzeba.
ZMIANA CZY BŁĄD?
Dość często zdarza się, że klient próbuje przemycić zmianę pod postacią błędu – jako że dostawca jest zobowiązany naprawić defekt w ramach usług gwarancyjnych – nieodpłatnie – a zmiany są z reguły w pełni odpłatne. Takich sytuacji nie da się uniknąć w prosty sposób – należy prowadzić dokładną i aktualną dokumentację wymagań opisującą jednoznacznie i przejrzyście, co jest w zakresie systemu. Pozwala to uniknąć nieporozumień i umożliwia o wiele prostszą identyfikację zmian.
Dokumentami, które są podstawą do określania zakresu systemu są:
- katalog (lista) wymagań
- specyfikacje wymagań użytkowników
- przypadki użycia
- modele biznesowe produktu
- specyfikacje interfejsu użytkownika
- słowniki danych
- specyfikacje architektury systemu
- specyfikacje interfejsów i dokumentacja mapowania danych
JIRA w zarządzaniu niezgodnościami.
JIRA to proste w obsłudze narzędzie do zarządzania zadaniami. Zadania definiowane są jako czynności do wykonania przez członków zespołu, błędy, żądania zmian, innego typu problemy.
Za pomocą JIRY użytkownicy mogą:
- planować prace, które należy wykonać i ustalać dla nich termin, osoby odpowiedzialne, a także monitorować stan wykonania
- tworzyć projekty, w których rejestrowane będą problemy dla określonego projektu czy dla określonych grup użytkowników (np. osobny projekt dla testów wewnętrznych udostępniony członkom zespołu oraz projekt dla testów klienta, do którego uprawnienia ma zespół projektowy oraz wybrane osoby z organizacji klienta)
- zgłaszać błędy w określonej kategorii, przydzielać błędy do naprawy oraz zarządzać ich cyklem życia według uprzednio zdefiniowanego przepływu stanów
- zgłaszać i zarządzać żądaniami zmian
JIRA umożliwia określenie czasochłonności danego zgłoszenia oraz planowanego czasu realizacji, dzięki czemu za jej pomocą można skutecznie planować prace implementacyjne i przygotowywać nowe wydania systemu. Ponadto narzędzie ma opcję (…) czytaj dalej (pobierz cały artykuł PDF):
http://sqam.org/magazine/1828-zarzadzanie-jakoscia-iso-9001-w-it-czesc-3-3
Społecznościowe
Artykuły
Kategorie TagiKategorie szkoleń
Typy szkoleń:
Ośrodki szkoleniowe
Dołącz do nas
Zarządzanie jakością. ISO 9001 w IT część 3/3 - Szkolenia, kursy, ciekawe artykuły na temat szkoleń. Informacje binzesowe oraz na temat podnoszenia swojej wiedzy.
© 2010 - 2024 Aplit.pl Wszelkie prawa zastrzeżone.