Jakość problemów informatycznych - problemy i rozwiązania

(1)

Jedenasta

Jakość systemów informatycznych Problemy i rozwiązania

Szczyrk, 2 1 -2 5 czerwca 1999 Dom wczasowy „Zagroń"

Polskie Towarzystwo Informatyczne

Oddział Górnośląski

(2)

(3)

Jedenasta Górska Szkoła P T I Szczyrk 999

^—

21-25 czerwca 1999

„Jakość systemów informatycznych

-

problemy i rozwiązania ”

(4)

(5)

Sz a n o w n i Pa ń s t w o

Nasze jedenaste świętojańskie spotkanie w Beskidzie nazwaliśmy z pewną dezynwolturą „Jakość systemów informatycznych - problem y i rozwiązania"

D ziesięć lat, które upłynęły od naszego pierw szego spotkania w tym miejscu przyniosło zdecydowanie więcej problem ów niż rozwiązań. Chyba najważniejsze, czego się

nauczyliśm y w tym czasie to fakt, że mamy jeszcze bardzo wiele do nauczenia się p rzed sobą.

Tegoroczna Szkoła zgromadziła, ja k co roku, przedstaw icieli wszystkich poważnych polskich producentów oprogramowania, użytkowników systemów informatycznych,

naukowców. Uważamy, że takie spotkania są najcenniejszą (w niczym nie ujmując świetnym Wykładowcom) częścią Szkoły. W czasie kuluarowych dyskusji okazuje się niekiedy, że gdy dwóch robi to samo, to wcale efekty nie muszą być identyczne.

Skutkiem takiego spotkania je s t zwykle popraw a p ra cy tych, którzy działają mniej sprawnie. Nie mieliśmy żadnych informacji o obniżeniu poziom u p ra c w jakiejkolw iek form ie, w wyniku udziału w szkole. Proszę zwrócić uwagę na tę sprzeczną z zasadam i

entropii tendencję.

Tegoroczna Szkoła je s t pierw szą konferencją PTI p o odbytym niedawno Zjeżdzie Towarzystwa. Jakkolwiek zjazd nie przyniósł rewolucyjnych zmian w działaniu PTI, to je d n a k istotnie odnowił i odmłodził skład Zarządu Głównego. W uchwale zjazdowej

znalazło się zalecenie zwrócenia w działaniach PTI uwagi na problem y szeroko rozumianej inżynierii oprogramowania.

W tym roku w Kazimierzu nad Wisłą odbędzie się w październiku organizowana przez P T I Pierwsza Krajowa Konferencja Inżynierii Oprogramowania. Jej pom ysł pow stał nie gdzie indziej, ja k w Szczyrku w czasie zeszłorocznej szkofy. W efekcie nastąpił rozdział dwóch nurtów obecnych w Szczyrku o d początku. Nurt teoretyczny znalazł swoje ujście w recenzowanej konferencji, pozostaw iając Szczyrkowi problem y bardziej praktyczne. Sądzimy, że taki rozdział dobrze będzie służył obu obszarom.

Zapraszając do aktywnego udziału w zajęciach szkoły zachęcam y również do niezam ykania oczy na piękno Beskidów na przełom ie wiosny i lata.

P io tr W. F u g le w ic z

(6)

(7)

Sz a n o w n i Pa ń s t w o

Nasze jedenaste świętojańskie spotkanie w Beskidzie nazwaliśmy z pew ną dezynwolturą „Jakość systemów informatycznych - problem y i rozwiązania”.

Dziesięć lat, które upłynęły od naszego pierw szego spotkania w tym miejscu przyniosło zdecydowanie więcej problem ów niż rozwiązań. Chyba najważniejsze, czego się

nauczyliśm y w tym czasie to fakt, że mamy jeszcze bardzo wiele do nauczenia się p rzed sobą.

Tegoroczna Szkoła zgromadziła, j a k co roku, przedstaw icieli wszystkich poważnych polskich producentów oprogramowania, użytkowników systemów informatycznych,

naukowców. Uważamy, że takie spotkania są najcenniejszą (w niczym nie ujmując świetnym Wykładowcom) częścią Szkoły. W czasie kuluarowych dyskusji okazuje się niekiedy, że gdy dwóch robi to samo, to wcale efekty nie muszą być identyczne.

Skutkiem takiego spotkania je s t zwykle popraw a p ra cy tych, którzy działają mniej sprawnie. Nie mieliśmy żadnych informacji o obniżeniu poziom u prac w jakiejkolw iek form ie, w wyniku udziału w szkole. Proszę zw rócić uwagę na tę sprzeczną z zasadam i

entropii tendencję.

Tegoroczna Szkoła je s t pierw szą konferencją PTI p o odbytym niedawno Zjeździe Towarzystwa. Jakkolwiek zjazd nie przyniósł rewolucyjnych zmian w działaniu PTI, to je d n a k istotnie odnowił i odmłodził skład Zarządu Głównego. W uchwale zjazdowej

znalazło się zalecenie zwrócenia w działaniach P TI uwagi na problem y szeroko rozumianej inżynierii oprogramowania.

W tym roku w Kazimierzu nad Wisłą odbędzie się w październiku organizowana przez P TI Pierwsza Krajowa Konferencja Inżynierii Oprogramowania. Jej pom ysł pow stał nie gdzie indziej, ja k w Szczyrku w czasie zeszłorocznej szkoły. W efekcie nastąpił rozdział dwóch nurtów obecnych w Szczyrku od początku. Nurt teoretyczny znalazł swoje ujście w recenzowanej konferencji, pozostaw iając Szczyrkowi problem y bardziej praktyczne. Sądzimy, że taki rozdział dobrze będzie służył obu obszarom.

Zapraszając do aktywnego udziału w zajęciach szkoły zachęcam y również do niezam ykania oczy na piękno Beskidów na przełom ie wiosny i lata.

P io tr W. F u g le w ic z

(8)

(9)

Jedenasta G órska Szkoła P T I S zczyrk’99^— 21-25 czerwca 1999 1

Barbara B egier

Politechnika Poznańska

e-mail: begier@ ai-kari.put.poznan.pl

Ogólne zasady inżynierii a poziom dojrzałości procesów tworzenia oprogramowania

XI Górska Szkoła PTI - Szczyrk 1999

Ogólne zasady inżynierii a poziom dojrzałości procesów

tworzenia oprogramowania

Barbara Begier Politechnika Poznańska

e-mail: begier@ai-kari.pat.poznan.pl

PO L S K IE T O W A R Z Y S T W O IN F O R M A T Y C Z N E — O D D Z I A Ł G Ó R N O Ś L Ą S K I

(10)

2 B arbara B egier — P olitech n ika P ozn ańska — O góln e zasady in żyn ierii a p o zio m dojrza ło ści procesów ..

XI Górska Szkoła PTI - Szczyrk 1999

Ogólne zasady inżynierii a poziom dojrzałości procesów

tworzenia oprogramowania

Barbara Begier Politechnika Poznańska e-mail: begier&ai-kari.put.poznan.pt

Inżynieria oprogram ow ania (1968) ustan a w ia n ie i sto so w a n ie so lid n ych za s a d in żyn ierii ir ce lu u zysk a n ia w sposó b eko n o m iczn y o p rogram ow ania, które j e s t nieza w o d n e i d zia ła

w yd a jn ie na

rzec zy w istej m a szyn ie ^

< « 7

Inżynieria oprogram ow ania ( Yingxit Wang, SEES'98) - dyscyplina,

która do tworzenia dużego oprogramowania adoptuje inżynierskie podejście, to jest ustanowione metodologie,

procesy, narzędzia, standardy, metody organizacji i zarządzania, systemy

zapewnienia jakości i inne, aby w rezultacie uzyskać wysoką produktywność,

niskie koszty, sterowalnąjakość i w y m i e r n y harmonogram opracowywania.

S ystem (A r th u r D. H all, 1962) j e s t to z b ió r o b i e k t ó w w ra z z relacjam i

p o m ię d z y tym i obiek tam i o ra z p o m ię d z y ich w łas n o śc ia m i.

O to c z e n ie danego systemu stanowi zbiór wszystkich obiektów nie należących do systemu, których własności oddziałują na system i zarazem ulegają zmianie pod wpływem działania systemu.

Inżynieria - p r o je k to w a n ie i k o n stru o w a n ie o b ie k tó w i u rzą d zeń te c h n ic zn y c h

Inżynieria syste m ó w (B e ll Labs, la ta 40.) - u to ż s a m ia n a z te c h n o lo g ią

pracy z e społow ej

P O LS KIE T O W A R Z Y S T W O IN F O R M A T Y C Z N E — O D D Z I A Ł G Ó R N O Ś L Ą S K I

(11)

Jedenasta Górska Szkoła P T I S z c z y r k ’99^— 21-25 czerwca 1999

Z g o d n ie z in ż y n ie rią s y s t e m ó w tw o rz e n ie s y s te m u o b e jm u je 5 faz

• B a d a n i a w s t ę p n e - b a d a n i e

p o t r z e b i o t o c z e n i a . 0 i

p l a n o w a n i e p r z e d s i ę w z i ę c i a 3 % ^ ,

• P i e r w s z a fa z a p r o j e k t o w a n i a - - p r o j e k t w s t ę p n y , w a r i a n t y

r o z w i ą z a ń , w y b ó r w a r i a n t u / O s u i - i - -

• D r u g a faza p r o j e k t o w a n i a - p l a n o w a n i e r e a li z a c ji s y s t e m u

• P i e r w s z a fa z a re a li z a c ji - p r o t o t y p y i ich b a d a n i a

• D r u g a faza r e a li z a c ji

Zadania inżynierii system ów

o p r a c o w a n i e z a s a d i n f o r m o w a n i e f o r m u ł o w a n i e p l a n ó w z a p e w n i e n i e m e t o d h a r m o n i z o w a n i e d z i a ł a ń o p t y m a l i z a c j a z a s o b ó w p r z e p r o w a d z a n i e k a ż d e j c z y n n o ś c i z u ż y c i e m o k r e ś l o n e j te c h n ik i

Pożądane cechy osobowe inżyniera

S y s t e m o m ' p u n k t w i d z e n i a ( c a ł o ś ć k o n c e p c j i ) R o z s ą d e k i o b i e k t y w i z m , p o d po rz ą d k o w a 11 ie w y m a g a n i o m W y o b r a ź n i a

Z r ę c z n o ś ć i d y p l o m a c j a w k o n t a k t a c h z. l u d ź m i D a r p r z e k o n y w a n i a ludz i U m i e j ę t n o ś ć k o r z y s t a n i a z d o ś w i a d c z e ń

/ ' A

Z a s a d y rz e c z o w e projek to w a n ia w g teorii p ro je k to w a n ia (C z. S zy m c za k )

• fizyczna u y konalność obiektu

• strukturalizacja procesu projektowania

• dekompozycja p r o b l e m u , a w następstwie projektu

• zwiększanie pewności wykonania projektu, zaniechanie projektów nierealnych lub nieefekt\ wnych

• dominująca rola koncepcji całości systemu

• komunikat\ w ność: pełny opis projektu, zgodność stosowanych definicji i oznaczeń

Z a s a d y n o r m a ty w n e p ro je k to w a n ia w g teorii p ro je k to w a n ia (Cz. S z y m c z a k )

• Z a s a d a z a s p o k o j e n i a p o t r z e b y ( k o n i e c z n o ś ć j e j o p is u )

• Z a s a d a w arto śei u ż y t k o w e j - w a rt o ś ć u ż y t k o w a o b ie k tu p o w i n n a b y ć eo n a jm n ie j r ó w n a k o s z t o m w y t w o r z e n i a

• Z a s a d a w y k o n a l n o ś c i f in a ns ow ej

• Z a s a d a m i n i m a l n e g o z a a n g a ż o w a n i a fi n a n s o w e g o

• Z a s a d a o p t y m a l n o ś e i - d o b ó r kry teri ów o c e n y i ich mi ar

• Z a s a d a j e d n o ś c i funk cji, fo rm y i k on s tr u k c ji - k o n i e c z n o ś ć ha rm o n ii , ś c is ła w sp ó ł p r a c a a u to ró w , k o m p r o m i s y

• Z a s a d a r ó w n o m i e r n e g o z u z y c i a

• Z a s a d a b e z p i e c z e ń s t w a i n i e z a w o d n o ś c i

Projektowanie tradycyjne stosowane do XIX wieku

• I n t e g r a c j a p r o c e s u p r o j e k t o w a n i a z p r o c e s e m re a li z a c ji w j e d n y m z e s p o l e (f ir m ie )

• S t o s o w a n i e m e t o d y p r ó b i b ł ę d ó w w o b e c b r a k u m e t o d b a d a n i a p o p r a w n o ś c i p r o j e k t u

• Z d o b y w a n i e p r a k t y c z n y c h k w a l i f i k a c j i p o d c z a s p r a c y

P O L S K IE T O W A R Z Y S T W O IN F O R M A T Y C Z N E — O D D Z I A Ł G Ó R N O Ś L Ą SK I

(12)

4 B arbara B egier — P olitech n ika P ozn ańska — O gólne zasady in żyn ierii a p o zio m dojrzałości procesów ..

M o d e lo w a n ie m a na celu badanie z a c h o w a n ia s y s te m u przy działaniu

ro z m a ity c h c z y n n ik ó w

mwfcfc w e u M y a m

S y m u la c ja - e k s p e ry m e n to w a n ie na m odelu, n a ś la d o w a n ie z a c h o w a n ia się

sy s te m u w ro z m a ity c h w a ru n k a c h i o k o liczn o śc ia ch

A w a ria - p rz e k ro c z e n ie ustalonej (zadanej a p r io r i) gra n ic y przez zm ie n n e okre ś la ją c e z a c h o w a n ie się

s y ste m u

Ocenie podlegają nic tylko własności techniczne i użytkowe projektowanego

systemu, ale również właściwości ekonomiczne oraz psychologiczno-estetyczne

ISO/IEC TR 15504 (15.08.1998)

1: Concepts a n d introductory guide

2: A reference mode! fo r processes a nd process capability 3: Performing and assessment

4: Guide to perform ing assessments

5: . In assessm ent m odel and indicator guidance 6: Guide to com petency o f assessors

7: Guide f o r use in process improvement

S: Guide fo r use in determ ining supplier process capability 9; I'ocabulary

Standard ISO/IEC 15504 pozwala:

• na uzy te k w ł a s n y fi r m y - o c e n i ć s ta n p r o c e s ó w w c el u o k r e ś l e n i a s p o s o b u ich u l e p s z e n i a

• o k r e ś l i ć o d p o w i e d n i o ś ć w y k o n y w a n y c h w o r g a n i z a c j i p r o c e s ó w do klasy w y m a g a ń

• o k r e ś l i ć o d p o w i e d n i o ś ć p r o c e s ó w d o s ta w c y d o p o t r z e b k o n k r e t n e g o k o n t r a k t u lu b k la s y k o n tr a k tó w

• r e d u k o w a ć n i e p e w n o ś ć n a b y w c y w w y b o r z e do s ta w c y

• z m n i e j s z y ć r y z y k o p r z e z u m o ż l i w i e n i e k o n tr o l i

• z a p e w n i ć p o d s t a w ę o k r e ś l e n i a r ó w n o w a g i m ię d z y p o t r z e b a m i , w y m a g a n i a m i i k o s z t a m i a m o ż l i w o ś c i a m i w y t w ó r c z y m i k o n k u r u j ą c y c h d o s t a w c ó w

Kontekst oceny procesów zgodnie z ISO/IEC 15504 '

Proccs

uicnufiktifi' m o ż ln itń u iikhiSkl :nm M \ / -*--- \ i r\z\k o

\l*nłl<W _ir _ _ f Ocerui

iiicpvL-mc ___ ______ y ’ oaiileiiT'S pfoccMi niirt\Mufc

P OLSKIE T O W A R Z Y S T W O I N F O R M A T Y C Z N E — O D D Z I A Ł G Ó R N O Ś L Ą SK I

(13)

Jedenasta G órska Szkoła P T I Szczyrk '99^— 21-25 czerwca 1999 ⁵

Model o ce n y procesów wg IS O /IE C 15504

■ O k r e ś l o n o k a t e g o r i e p r o c e s ó w r e a l i z o w a n y c h p r z e z d o s t a w c ę , p r z e n i e s i o n e n i e m a l d o k ł a d n i e z I S O 122 07:

d la k a t e g o r i i z i d e n t y f i k o w a n o p r o c e s y s k ł a d o w e

• D l a c a ł y c h k a t e g o r i i o r a z p r o c e s ó w s k ł a d o w y c h z d e f i n i o w a n o o c z e k i w a n e r e z u lt a ty , k tó r e s t a n o w ią p o d s t a w ę o c e n y d a n e g o p r o c e s u

• P r z y j ę t o 6- s t o p n i o w ą s k a lę o c e n y d o jr z a ło ś c i p r o c e s ó w - 5 s t o p n i o b e c n y c h w m o d e l u C M M o r a z p o z i o m z e r o w y d l a n i e o b e c n e g o lu b n i e k o m p l e t n e g o p r o c e s u

■ N a d a n y m p o z i o m i e d o j r z a ł o ś c i p r o c e s o p i s u j e z e s t a w a t r y b u t ó w , k t ó r e s t a n o w i ą k r y te r i a p r z e p r o w a d z a n e j o c e n y k a ż d e g o p r o c e s u d o s t a w ę ;

Oceniane kategorie procesów

• CUS: działania na styku 'klicnt-dostawca' od formułowania kontraktu po przekazanie oprogramow ania z zapewnieniem jego prawidłowego użytkowania i serwisu

• ENG: specyfikówanie, implementacja, dokumentowanie, pielęgnacja

• SUP: procesy wspomagające

• MAN: zarządzanie przedsięwzięciem

• ORG: określenie celów organizacji dostawcy i metod ich osiągania: zarządzanie zasobami

Procesy cyklu życia oprogramowania według ISO/IHC 12207 Podstawowe procesy cyklu życia Procesy wsponiaf>ajqcc

1 .Pozyskiwanie oprogramowania ] 1 Dokumentowanie - ■ ■ 2 Zarządzanie konfiguracją

| 2.Działania dostawcy 1 3. Zapewnianie jakości 3. Rozwój

oprogramo

wania

4. Użytkowanie 1 Wen flkacja

f 5. Zatwierdzanie (walidacja)

5. Pielęgnacja 1

| 6. Wspólne przeęlądy [ 1. Audity

R Rozwiaz> wanie pioblcmów

Procesy organizacyjne cyklu życia

¡1 Zarządzanie f-- Zapewnienie infrastruktury!

3. Doskonalenie procesów | | -1. Szkolenie personelu

C M M - Capability M aturity Model

j Padom 5 optymalizowany: / - ustaw ic/jw d os Lora ku u-

! Poziom A zarządzam; miary proetfu i jakości produktu

r... z i z z : ... J

J P o z io m 3 z d c f i n i iM a iw j C ^ D s ta n d a n z o u a n s . udoku m em u w nm p r o c o

r.... i z z z : ... J

•P oziom 2 p o \u arz aln j£ C— * podstaw o w e p io cesy zarząd zania :... Y... !

... Z ...,

Poziom 1 początkowy' C _ J procesy ikI Ihh. . brak dokumentacji pioccsou

Rezultaty prawidłowej realizacji np. procesu CUS.4 {requirements elicitation process)

• U s t a n o w ie n ie c ią g łe j k o m u n ik a c ji z kl ie n te m

• Z d e f i n i o w a n e w y m a g a n i a i z g o d a k li e n ta

• U s t a n o w i o n y m e c h a n i z m w łą c z a n ia n o w y c h \ \ \ m a g a ń

• Ust ano w io n y m e c h a n i z m c i ą g ł e g o m o n i t o r o w a n i a p ot rz e b k lie nta

• U s t a n o w i o n y m e c h a n i z m z a p e w n ia ją c y k li e n to w i m o ż l i w o ś ć o k r e ś l e n i a statusu wv m a g a ń

• Z m i a n a t e c h n o l o g i i o r a z p o tr z e b k li e n ta b ę d z i e id e n t\ tik ów an a. a ich w p l \ w n a p ro c e s y z a r z ą d z a m

Atrybut procesu na poziomie 1:

- PA I 1 a t r y b u t wy k o n a n i a p r o c e s u Atrybuty procesu na poziomie 2:

- P A 1.1 a t r y b u t wy k o n a n i a p r o c e s u - P A 2.1 a t r y b u t z a r z ą d z a n i a w y k o n a n i e m - P A 2.2 a t r y b u t z a r z ą d z a n i a p r o d u k t e m p r o c e s u A t r y b u t y p r o c e s u n a p o z i o m i e 3:

- P A 1.1 atry b u t w y k o n a n i a p r o c e s u - PA 2 1 a t r y b u t z a r z ą d z a n i a w \ k o n a n i e m - P A 2.2 a t r y b u t z a r z ą d z a n i a p r o d u k t e m p r o c e s u - P A 3 . 1 a t r y b u t d e fi n ic ji p r o c e s u

" , , N (nut u ilm ia t) 0-1

- P A j . 2 airy b u l z a s o b o w p r o c e s u , , ^ |6 }0>,

l t d . ,L (farxi'ł\ ). 51 -85° o,

' I- {full\) 86-! 00° o

POLS KIE T O W A R Z Y S T W O IN F O R M A T Y C Z N E — O D D Z I A Ł G Ó R N O Ś L Ą S K I

(14)

6 B arbara B egier — P olitech n ika P ozn ań ska — O góln e zasady in żyn ierii a p o zio m dojrzałości procesów ..

Forma zapisu wyniku occny dojrzałości procesów

Airybttiy procesów charakterystyczne dla po/i o 111 ów I I 2.1 2.2 3.1 3.2 J.l 42 5.1 ^5.2

= CUS.I V CUS.2

-i eus,.?

5 CUS.4 , 2 FNG.I i FNG.2 F i ENG.3 P -

Przeprowadzenie oceny procesów

• Założenie powtarzalności procesu oceny

• Zdefiniowanie zakresu oceny oraz danych wejściowych przed zbieraniem danych do oceny

• Dobór zespołu oceniającego i jego lidera

• Zaplanowanie oceny

• Zidentyfikowanie technik analizy i oceny danych oraz ocenianych procesów przed oceną

• Zatwierdzenie danych podlegających ocenie

• Podjęte drogą glosowania decyzje są raportowane.

Inspektor nadzoru

Pożądane uregulowania prawne

O M lIH lM B K O ] J

^.

1

^ * •*

^<

— a j »

'

U

M onitorowanie przedsięwzięć publicznych w zakresie

informatyzacji przez niezależnych obserwatorów

POLSKIE T O W A R Z Y S T W O IN F O R M A T Y C Z N E — O D D Z I A Ł G Ó R N O Ś L Ą S K I

(15)

Jedenasta G órska Szkoła P T I Szczyrk '99^— 21-25 czerwca 1999 7

H enryk Krawczyk

Wydział Elektroniki, Telekomunikacji i Inform atyki Politechnika Gdańska

Streszczenie: Przedstaw iono p ro b lem y m etrologii oprogram ow ania i j e j w ykorzystanie w procesie oceny ja ko ści aplikacji informatycznych. Zaprezentow ano m etodologię pom iarów , narzędzia w spom agające wykonywanie eksperym entów p om iarow ych oraz sposo by opracowania i prezentow ania wyników pom iarow ych.

1. W p ro w a d z e n ie

Metrologia jest dziedziną nauki i techniki obejmującą zarówno teorię pomiarów (pojęcia podstawowe, modele, metody, wzorce) jak i praktykę ich wykonywania (eksperymenty, narzędzia, laboratoria, jednostki miar) [7], Głównym pojęciem metrologii jest więc pomiar.

Rozumie się przez to zespól czynności wykonywanych w celu ustalenia miary określonej wielkości. N a ogół wielkość mierzoną a porównujemy z elementami wzorca cii, a 2, ... a,, i stwierdzamy w wyniku pomiarów', że a e <a„ a,,i>. Szerokość przedziału <a„ cx;ł j> jest dokładnością pomiarów i zależy od klasy przyrządu pomiarowego. W celu zapewnienia wysokiej wiarygodności pomiarów przyrządy pomiarowe powinny być legalizowane i okresow'o uwierzytelniane przez odpowiedni organ rządowy w cclu stwierdzenia, zc spełniają wymagania ustalone w przepisach międzynarodowych. Dokładność pomiarów' zależy również od przyjętej metody pomiarowej. N a ogól wyróżniamy metody pomiarów bezpośrednich (np. długość pudelka)

i pośrednich (pomiar objętości pudełka). W tym drugim przypadku istotne jest zapewnienie odpowiedniej dokładności pomiarów bezpośrednich by otrzymać wymaganą dokładność pomiaru pośredniego.

Metrologia oprogramowania przejmuje wiele pojęć i metod z tradycyjnej metrologii dotyczącej pomiarów wielkości fizycznych.

W tym jednak przypadku obiektem zaintere

sowania jest aplikacja oraz inne produkty wytworzone w całym cyklu życia oprogramo- w'ania (patrz tabela 1). Produkty te znacznie różnią się od typowych obiektów fizycznych, gdyż dominującą ich cechą jest różna postać informacji a nie pewne wiasności materii. Co więcej metrologia oprogramow'ania odgrywa istotną rolę w' inżynierii oprogramowania z uwagi na następujące fakty:

• jest narzędziem w inżynierii jakości oprogramowania,

• wspomaga proces wytwarzania i utrzymania oprogramowania,

« obiektywizuje ocenę i audyt oprogramowania.

P O L S K IE T O W A R Z Y S T W O IN F O R M A T Y C Z N E — O D D Z I A Ł G Ó R N O Ś L Ą S K I

(16)

8 H en ryk K raw czyk — P olitech n ika G dańska — N arzędzia i eksperym en ty p o m ia ro w e oprogram ow an ia

Tabela I . Podstawowe produkty wy twarzane w cyklu życia oprogramowania Faza życia

Oprogram ow ania Podstawowe produkty aplikacji informatycznej

Specyfikacja Dokumentacja specyfikacji

Analiza Dokumentacja analizy

Projekt Architektura (komponenty)

Implementacja Kod źródłowy, kod binarny

Testowanie Konfiguracja systemu, dokum entacja testowa Eksploatacja Raporty o zachowaniu się aplikacji

Wycofanie Protokół kasacji

Definiowanie scenariuszy testowych

i pomiarowych

Analizowanie wyników testów i pomiarów'

Rys I. Rola pom iarów w cyklu w y tw arzania oprogram ow ania

POLS KIE T O W A R Z Y S T W O I N F O R M A T Y C Z N E — O D D Z I A Ł G Ó R N O Ś L Ą S K I

(17)

Jedenasta Górska Szkoła P T I S zc zy rk ’99^— 21-25 czerwca 1999 9

Rysunek 1 przedstawia rolę pom iarów w procesie wytwarzania oprogramowania.

Złożone aplikacje informatyczne realizowane czy to w modelu kaskadowym czy spiralnym w y m ag a ją w ykonania wielu iteracji [3,4], w których uściśla się zarówno stawiane im w ym agania, ja k również podejmuje się różne

go typu decyzje o modyfikacji produktów w celu zapewnienia odpowiednich charakte

rystyk jakościow ych końcowemu produktowi.

Metrologia oprogram owania jest istotna zarówno przy podejmowaniu decyzji lokal

nych dotyczących poszczególnych kom ponen

tów aplikacji, j a k i globalnych dotyczącej całej aplikacji.

W pracy przedstawiono wybrane problemy metrologii oprogram owania z punktu widzenia inżynierii jakości. D otyczą one przygotowania eksperymentów pomiarowych (wielu pom ia

rów zadanych charakterystyk), ja k i narzędzi w spom agających ich wykonanie oraz analizę otrzymanych wyników.

2. M etrologia oprogram ow ania jak o narzę

dzie oceny jak ości

Z rozważań przedstawionych w poprze

dnim rozdziale wynika, że przedmiotem pom iarów m o g ą być zarówno produkty wytwarzane w cyklu życia oprogram owania jak o towarzyszące im procesy oraz oczywiście wykorzystywane zasoby. Rys. 2 przedstawia zakres metrologii oprogramowania uwzglę

dniający wszystkie te aspekty odnoszące się

w zasadzie do produktu końcowego, tj.

programu wytworzonej aplikacji. W przy

padku produktu oceniać m ożem y jego charakterystyki statyczne, tzn. odnoszące się do kodu źródłow ego charakterystyki dynam i

czne uwzględniające zachowanie się programu podczas je g o wykonyw ania się w zadanym środowisku [1,2]. W tym drugim przypadku pojawia się nowa trudność dotycząca powtarzalności pomiarów. W ym aga to zapew

nienia jednakow ych w arunków wykonania się aplikacji. Dotyczy to nie tylko podania tych sam ych danych na wejście programu, ale również odtworzenie stanu środowiska w którym aplikacja będzie wykonana. To drugie zdanie m oże być trudne do zrealizo

wania w przypadku system ów sieciowych czy rozproszonych.

Wykonanie pomiarów dla procesów wytwarzania aplikacji je s t jeszcze bardziej trudniejsze, gdyż należy uwzględnić takie niewym ierne charakterystyki ja k wysiłek pro

jektowania, je g o koszt, harmonogram w ytw a

rzania czy częstość zm ian dokonywanych w produktach. W ym aga to interdyscyplinarne

go podejścia integrującego punkty widzenia dotyczące zarządzania, ekonomii, psychologii czy metodologii wytwarzania. W przypadku oceny wykorzystywanych zasobów, które dotyczą zarówno ludzi jak i używ anych przez nich narzędzi, techniki pom iarowe powinny uwzględniać różne aspekty: techniczne, organizacyjne a nawet psychologiczne.

(18)

10 Henryk Krawczyk— PolitechnikaGdańska— Narzędziai eksperymentypomiaroweoprogramowania

Produkt

P rz e d m io t p o m ia ró w

i

Wykorzystywane zasoby

Własności statyczne

/ ' I \

Złożoność I Dokumentowałność

Własności dynamiczne

Elastyczność Wiarygodność

Obiektowość Strukturałność

Organizacja Doświadczenia projektantów

LProcesy

Wysiłek \ Harmonogram projektowania V wytwarzania

Koszt

Renoma firmy Motywacja

Użyteczność

Analiza \ Eksploatacja

Projektowanie ...

Łatwość obsługi Zrozumiałość

Rys 2. Zakres metrologii oprogramowania

^PO

LSKIE TOWARZYSTWOINFORMATYCZNE—ODDZIAŁGORNOSLĄSK1

(19)

Jedenasta G órska Szkoła P T I S z c z y r k ’99^— 21-25 czerwca 1999 11

Tabela 2 Opis charakterystyk jakości oprogramowania

Atrybuty Charakterystyki Opis charakterystyk

Funkcjonalność

Kompatybilność Złożoność Adekwatność Integralność Możliwość śledzenia

Wyczerpujący zbiór funkcji aplikacji Skomplikowanie produktu i je g o elementów Dopasowanie funkcji do zadań aplikacji Spójność aplikacji ja k o całości

Powiązanie różnych reprezentacji aplikacji

Wydajność

Efektywność Skalowalność Stabilność Interakcyjność

Szybkość działania aplikacji

Liniowe przyspieszenie obliczeń wraz ze wzrostem liczby przerwań

Niezmienność osiągów wraz ze zmianą platformy programowej

Szybkość komunikacji z użytkownikiem

Wiarygodność

Niezawodność Testowalność Odporność Bezpieczeństwo Zabezpieczenie

Częstość pojawiania się błędów Zdolność identyfikacji błędów Tolerowanie skutków błędów Zapobieganie sytuacjom krytycznym Kontrola dostępu do aplikacji

Satysfakcja

Łatwość użycia Zrozumiałość Łatwość nauki

Produktywność Akceptacja

Prostota obsługi

Zrozumienie aplikacji na podstawie jej opisu Wysiłek dla umiejętnego obsługiwania aplikacji Stopień wspomagania aplikacji przez system

Akceptacja niefunkcjonalnych wymagań użytkownika

Elastyczność

Przenośność Modyfikowalność Konfigurowalność Łatwość testowania

Przystosowanie do nowych platform Łatwość dokonania zmian wymaganych przez środowisko

Możliwość dopasowania do nowych potrzeb użytkownika

Prostota projektowania i wykorzystania testów

Na dzisiejszym etapie rozwoju metrologii oprogram owania wykonanie wielu z wyżej wymienionych eksperymentów pomiarowych nie jest możliwe. Najważniejszym ogniwem kompleksowego procesu oceny je st nadal człowiek z je g o dużym doświadczeniem i nie

zrozumiałą ja k dotąd intuicją. Dla dobrze zdefiniowanych modeli jakości [5] można opracować precyzyjne eksperymenty pom iaro

we. Wiele z nich może być wspom agane odpowiednimi narzędziami pomiarowymi dotyczącymi wybranej charakterystyki czy metryki. W tabeli 2 przedstawiono główne atrybuty jakości oraz odpowiadające im cha

rakterystyki jakościow e. Wiele z nich może być bezpośrednio zmierzone bądź estymowane

na podstawie pomiarów historycznych albo szacowane przez ekspertów. Pojawia się pro

blem, j a k zagospodarować te wszystkie wyniki pomiarowe i w jaki sposób dokonywać cało

ściowej lub wybiórczej analizy jakościowej oprogramowania.

3. N arzęd zie Q E SA

Różne m ogą być metody oceny jakości wspom agane odpowiednim narzędziem pomiarowym [8], Poniżej ograniczę się tylko do prezentacji oryginalnej metodologii, która integruje różne podejścia. M etoda ta bazuje na opracowanym narzędziu QESA [6], którego ogólna architekturę przedstawia rysunek 3.

P O L S K IE T O W A R Z Y S T W O I N F O R M A T Y C Z N E — O D D Z IA Ł G Ó R N O Ś L Ą SK I

(20)

1 2 H e n ry k K raw czyk — P olitech n ika G dańska — N arzędzia i eksperym en ty p o m ia ro w e oprogram ow an ia

Rys 3. Architektura systemu pomiarowego

W proponowanej metodologii oceny jakości wyróżnia się następujące kroki postępowania:

1. Definicja modelu jakości (opis trójpo- ziomowego drzewa: atrybuty - chara

kterystyki - metryki; patrz tabela 2).

2. Zaplanowanie odpowiednich do modelu jakości eksperymentów pomiarowych bezpośrednich i pośrednich umożli

wiających utworzenie zależności bada

nej charakterystyki lub metryki od poda

nych param etrów aplikacji i/lub określo

nych parametrów środowiska w którym ta aplikacja będzie wykonywana.

3. Wykonanie pomiarów i utworzenie dokumentu jakości, który przechowuje otrzymane dane pomiarowe, j a k również inne zadane parametry.

4. Analiza dokumentu jakości z ew entu

alnością uzupełnienia pomiarów (powrót do punktu 2) oraz podjęcie decyzji o zapamiętaniu dokumentu jakości w historycznej bazie danych.

5. Analiza uogólnionych zależności na podstawie historycznych dokum entów jakości dotyczącej danej klasy aplikacji bądź wybranej fazy życia konkretnej aplikacji, z m ożliwością odtworzenia i uzupełnienia niektórych historycznych eksperym entów pomiarowych.

Prezentowana metodologia oceny jakości posiada następujące cechy:

— uniwersalność określona przez możliwość analizy różnych aplikacji, dzięki standardowemu interfejsowi pomiędzy konkretnym narzędziem pomiarowym a jądrem pakietu QESA,

— elastyczność wyrażona poprzez dobór odpowiedniego modelu jakości w zależno

ści od potrzeb użytkownika oraz sugestii eksperta co do ważności poszczególnych atrybutów czy charakterystyk oraz relacji między nimi,

— rozbudowywalność dzięki wydzieleniu biblioteki narzędzi pomiarowych i proce

dur wspomagających analizę jakości oraz możliwości dołączania nowych przydat

nych do realizacji innego typu ekspery

mentów' pomiarowych bądź umożliwiają

cych dodatkowe wnioskowanie ma podstawie dostępnych dokumentów jakości,

— bieżąca prezentacja wyników oceny pozwalająca na łatwe zorientowanie się, które z eksperymentów zostały zakończo

ne oraz które w ym agają dalszego wykonania bądź powinny być powtórzone.

P O L S K IE T O W A R Z Y S T W O IN F O R M A T Y C Z N E — O D D Z IA Ł G Ó R N O Ś L Ą S K I

(21)

Jedenasta G órska Szkoła P T I Szczyrk ’99^— 21-25 czerwca 1999 13

Tak wiec pakiet QESA nie je st narzędziem oceniającym wszystkie atrybuty charakterysty

ki, czy metryki jakości oprogramowania, raczej wspom aga organizację takiego procesu oraz zapewnia przechowywanie reprezenta

tywnych wyników pomiarów. M oże więc być łatwo włączony do procesu iteracyjnego wytwarzania oprogramowania przedstawio

nego na rys. 1.

4. W n iosk ow an ie o jak ości aplikacji

Ocenę jakości stanowić może jedna konkretna wartość ogólnego wskaźnika jakości, zbiór takich wartości, bądź zestaw reprezentatywnych charakterystyk zdjętych podczas wykonania różnych eksperymentów pomiarowych. Każda z tych form prezentacji ma swoje wady i zalety, dlatego w praktyce istotną rolę odgrywa właściwa forma wizualizacji.

Pakiet QESA posiada trzy różne formy wizualizacji wyników pomiaru i oceny jakości:

— w formie odpowiednich tabel zawiera

jących mierzone lub ocenione wartości,

— w formie uogólnionego diagramu kołowego, gdzie poszczególne wyniki reprezentuje wartość poszczególnych parametrów (atrybutów, charaktery

styk lub miar) z możliwością przedstawienia wzajemnych powiązań,

— w formie wykresów podających estymowane i rzeczywiste wartości danego parametru jakości dla poszczególnych faz wytwarzania aplikacji (patrz rys. 4).

Parametr jakości

fazy

Rys 4. Wizualizacja dowolnego parametru jakości w cyklu życia oprogramowania

Ostatnia forma prezentacji możliwa jest dzięki zapamiętywaniu dokum entów jakości dotyczą

cych poszczególnych baz wytwarzania danej aplikacji. Jesteśmy w stanie określić nie tylko poszczególne wartości parametrów, ale dokładność ich estymacji lub pomiarów w poszczególnych fazach życia oprogramo

wania. Taki wykres dostarcza nie tylko informacji o procesie wytwarzania, ale może stanowić podstawę do doskonalenia samych procedur pomiarowych.

Prezentowana metodologia oceny posiada jeszcze inną zaletę. Dzięki rozpoznaniu różnych tendencji i zależności istniejących w procesie wytwarzania może proponować wartości wybranych parametrów jakości w danej fazie cyklu życia na podstawie znajomości innych lub tych samych parametrów w poprzednich fazach cyklu życia.

Doskonalenie metod prognozowania może prowadzić do minimalizacji liczby w ykony

wania czasochłonnych i kosztownych procedur pomiarowych.

P O L S K IE T O W A R Z Y S T W O IN F O R M A T Y C Z N E — O D D Z IA Ł G Ó R N O Ś L Ą SK I

(22)

1 4 H enryk K raw czyk — P olitech n ika G dańska — N arzędzia i eksperym en ty p o m ia ro w e oprogram ow an ia

5. Uwagi końcowe

W pracy zaprezentowano nową m etodolo

gię oceny jakości aplikacji wykorzystującą różne techniki pomiarowe oprogramowania.

Metodologia ta została zaim plem entowana

i jest dostępna w postaci pakietu QESA, który m oże być konfigurowalny i rozbudowywaliby w zależności od potrzeb konkretnego użytko

wnika. W aktualnej wersji bierze się pod uwagę jedynie ocenę produktów w ytw orzo

nych w różnych fazach życia oprogramowania.

B ibliografia

[I ] D rake T.: M easuring Softw are Q uality: A Case Study. IEEE C om puternov., 1996.

[2] Fenton N .E. et al.: Softw are M etrics. A R igorous & Practical A pproach. Int. T hom son C o m puter Press, 1995.

[3] Jóźw iak L., O ng S.A.: Q uality -D riv e n D ecision M aking M ethodology gfor S ystem -L evel D esign. Proc.

o f E U R O M IC R O - 22, 1996.

[4] K raw czyk H., W iszniew ski B.: A nalysis and testing o f D istributed S oftw are A pplications. Research Studies Press Ltd., B aldock, H ertfordshire, England, 1998.

[5] K raw czyk H.: M odele i ocena jak o ści system ów in form atycznych. M ateriały 14-ego Jesiennego S potkania PTI, M rągow o, 1998.

[6] K raw czyk H., Sikorski, M., S zejko, S., W iszniew ski, B. "A tool for quality evaluation o f parallel and distributed softw are applications". Int. C onf. Parallel Processing and A pplied M athem atics, PPA M '99.

[7] Piotrowski J.: T eoria pom iarów . PW N , W -wa, 1986.

[8] Pressm an RS: Softw are E ngineering: A Practical A pproach. M cG raw -H ill, Inc., 1992

P O LS KIE T O W A R Z Y S T W O IN F O R M A T Y C Z N E — O D D Z I A Ł G Ó R N O Ś L Ą S K I

(23)

Jedenasta Górska Szkoła P T I Szczyrk '99^— 21-25 czerw ca ¡999 ¹⁵

M arek M iłosz

Politechnika Lubelska Katedra Inform atyki

e-mail: marekm(a>x)luton.poUublin.pl

Jakość systemów informatycznych: między teot ią a praktyką

R eferat p rzedstaw ia p ro b lem y zw iązane z ja k o śc ią system ów inform atycznych i dw a po dejścia do pro cesu zapew nienia ja ko ści: w eryfikacja p ro d u ktu i p ro ce su je g o w ytworzenia. Szczegółow o został om ów iony m odel E F Q M i je g o zastosow anie do oceny i p o rów nan ia ja k o śc i p rocesów w fir m a c h informatycznych.

1. Jakość i jej w ym iar ekonom iczny

Definicji jakości system ów informaty

cznych (i nie tylko) jest wiele. Zwykle posłu

gują się one pojęciem „zgodności z w y m ag a

niami użytkownika” i „zaspokojenie potrzeb klienta”, czasem „zgodność ze standardam i”, lub też definiują jakość jak o „ogół cech i właściwości wyrobu lub usługi, które decydują o zdolności wyrobu lub usługi do zaspokojenia stwierdzonych lub przewidywa

nych potrzeb” (ISO 8402). Definicje te bardzo ogólnikowo traktują problem. Zaspokajać

„stwierdzone potrzeby” m ożna oprogram ow a

niem, które raz na godzinę zawiesza system.

Z drugiej strony, jeśli potrzeby użytkownika s ą związane ze 100% gotowością systemu (np.

oprogram owanie bankomatu) to żaden system informatyczny ich nie spełni.

Problemem jest zatem definiowalność (stwierdzenie a, zgodnie z definicją, nawet przewidywanie) potrzeb użytkownika. Kto ma

j e definiować? Użytkownik. Z w ykle ma on dość ograniczone pojęcie o własnych potrze

bach i ich zaspokajaniu. Ponadto użytkownicy są różni - co jednem u je s t potrzebne w SI to innemu m oże przeszkadzać. W ym agania użytkowników zm ieniają się także w czasie.

Trudno więc jest zdefiniować je w jeden spójny i niezmienny w czasie sposób. Ale tak czy owak potrzeby użytkowników trzeba prze

widywać i zaspokajać. Tylko kto to powinien robić i kto za to zapłaci?

Jakość systemu inform atycznego (SI), niezależnie j a k jest pojm ow ana i mierzona, związana jest bowiem w ścisły' sposób z kosztami. Koszty jakości składają się z dwóch elementów: kosztu zapewnienia jakości i kosztu strat, związanych z jej

brakiem [10]. Oba koszty m ają przeciwstawne tendencje, tzn. pierwszy rośnie wraz z wysiłkami projakościowymi a drugi maleje (rys. 1).

P O LS KIE T O W A R Z Y S T W O I N F O R M A T Y C Z N E — O D D Z I A Ł G Ó R N O Ś L Ą S K I

(24)

16 M arek Miłosz — Politechnika Lubelska — Jakość systemów informatycznych: tniędzy teorią a praktyką

Wzrost kosztów

zapewnienia jakości

Możliwe straty

Działania zwiększające jakość

Rys. 1. Tendencje zm iany kosztów system ów inform atycznych, zw iązanych z działaniam i projakościow ym i

Dodatkowy koszt (straty) związany z j a kością przy braku jakichkolwiek działań zape

wniających tą jakość je st duży, ale możliwy do policzenia. Składają się na niego wszelkiego typu dodatkowe koszty utrzymania systemu, straty biznesowe (np. obniżenie sprzedaży) czy też m arketingow e (np. utrata wiarygodności).

Są one ponoszone przez klienta - użytkownika

SI. '

Minimalizacja do zera możliwych strat użytkowników SI jest związana ze wzrostem (praktycznie do nieskończoności) kosztów zapewnienia jakości. Na koszty te składają się koszty:

• opracowania systemu spełniającego wszystkie zdefiniowane (a także prze

widywalne) wym agania klienta;

• identyfikacji, które produkty nie spełniają ww. kryteriów;

• poprawy (i wym iany) zidentyfikowanych produktów.

Koszty te są oczywiście ponoszone przez producenta - dostawcę SI.

„Cena jak o ści” (tj. koszty łączne) posiada zatem pewien punkt optymalny, leżący pomiędzy obydw om a skrajnymi przypadkami.

Można nazwać go punktem op tym a ln ej ja k o ś c i systemu informatycznego, satysfakcjo

nującej obie strony: dostawcę i klienta.

Problem polega na je g o znalezieniu, a także na

osiągnięciu swoistego konsensusu pomiędzy dostaw cą i klientem. Polega on na tym, że każda ze stron musi ponosić koszty, związane z jakością systemu informatycznego.

U dostawcy są to koszty zapewnienia jakości, a u klienta - zw iększone koszty eksploatacji czy też utracone korzyści.

Z w ykle to klient dyktuje warunki, ale też i za wszystko płaci. Decydując się zatem na

„w ysoką ja k o ść ” wie, że będzie musiał za nią odpowiednio dużo zapłacić. Zrobi to tylko w sytuacji, kiedy dodatkowe koszty zw rócą się brakiem strat. To dlatego jedni w ykorzystują systemy informatyczne w cenie 100. czy 200.

złotych (ale je żą ce się od błędów lub ogra

niczone funkcjonalnie) a inni płacą znacznie więcej za podobne produkty innych producen

tów i o innej jakości. Przeniesienie na klienta kosztów jakości systemu informatycznego znajduje zwykle odwzorowanie w niskiej cenie produktu. I to jest normalne (zresztą nie tylko w informatyce). Patologią są natomiast sytuacje, kiedy z tego przeniesienia dostawca czerpie nadm ierne korzyści i nadmiernie obciąża klienta. Jest to szczególnie groźne zjawisko w przypadku oprogramowania powielarnego, którego koszty kopiowania i dystrybucji są niewielkie a klientów dużo.

Przy niskich nawet kosztach jednostkowych łączne straty klientów są wówczas ogromne.

Duże są za to oszczędności dostawcy SI.

(25)

Jedenasta Górska Szkoła P T I S z c z y r k ’99^— 21-25 czerwca 1999 17

2. Problem y jak ości system ów inform a

tycznych

Systemy informatyczne s ą specyficznymi produktami w wielu aspektach, w tym i jakościow ym . Posiadają cały szereg cech wyróżniających je od innych produktów lub usług. Są to:

• ab stra kcyjn o ść i złożoność S I - cecha ta powoduje, że trudno jest zdefiniować parametry charakteryzujące atrybuty j a k o ści systemu i jeszcze trudniej j e zmierzyć;

atrybuty te powinny odwzorowywać wiele różnych aspektów SI;

• n iew łd zia ln o ść system ów in fo rm a ty  cznych - cecha ta wynika z abstrakcyj- ności SI ale też jest związana z szerszym problemem, w tym i nieujawnianiem przed dostawców szczegółów architektury syste

m ów czy też kodu źródłowego progra

mów; dostawcy postępują tak z różnych powodów — przeważnie jest to element ochrony praw autorskich lub też wynika on ze złożoności danego elementu SI; dość często klient nie ma żadnej możliwości skontrolowania zakupionego produktu, nawet w sytuacji gdy otrzyma pełną jeg o dokumentację;

• je d n o stk o w o ś ć system ów in fo rm a tyczn yc h - większość SI jest tworzona (nie należy mylić ze sprzedażą, która jest rezultatem prostego i łatwego powielania raz w ytw o

rzonego SI) jak o „produkcja” jed n o stk o wa, w sensie niepowtarzalnych warunków (w tym i w ym agań) jej realizacji; j e d n o stkowość produkcji w ym usza inne podejście do problemów' jakości niż w przypadku produkcji masowej (np.

praktycznie bezużyteczne są statystyczne miary jakości produktów) przy zachow a

niu pewnych elementów masowej pro

dukcji (np. wielu klientów' kupujących dany produkt - możliwość rozłożenia kosztów - ale też i problemów' - na wielu klientów');

• w ie/ow arstw ow ość S I - cecha ta prowadzi do rozm ycia odpowiedzialności” za pro

dukt; Si je st bowiem systemem składają

cym się z różnych elementów, pochodzą

cych od różnych dostawców; użytkownik nie wie kogo obarczyć odpowiedzialnością za błędne działanie SI; w sytuacji wielu

różnych dostawców elementów' składo

wych SI stwarza to możliwości różnych nadużyć dostawców w stosunku do klienta:

trudno jest bowiem zdefiniować obszar odpowiedzialności poszczególnego dostaw

cy; pewnym wyjściem z tej sytuacji jest korzystanie ze specjalnego typu dosta

wców SI - integratorów, którzy przyjm ują odpowiedzialność za połączenie w je d n ą całość wielu warstw' SI;

• bra k je d n o zn a c zn y c h m ia r ja k o ś c i S I - nie jest możliwe stworzenie jednolitego systemu pomiaru jakości SI opartego o wielkości kwantyfikowalne i j e d n o znacznie mierzalne; problemem jest różnorodność (i słaba definiowalność) w ym agań użytkowników (również tych samych ale w różnym czasie), różno

rodność cech jakości i ich wag (subiekty

wizm ); większość system ów bazuje na ocenach ekspertów i/lub ankietach, a zatem na subiektywnych ocenach ludzi;

• bra k m ożliw ości p r a k ty c z n e j w eryfika cji ja k o ś c i S I a p rio ri - cecha la jest zw iąza

na z brakiem miar, a w konsekwencji z brakiem możliwości jednoznacznego wyspecyfikowania „stwierdzonych lub przewidywanych potrzeb” ; nie można także zweryfikować jakości SI z przyczyn

„obiektywnych” - brak jest fizycznych możliwości zupełnego (tj. wyczerpującego wszystkie możliwości) przetestowania nietrywialnego SI [6]; problem leży po obu stronach, ale przede wszystkim wyni

ka z braku orientacji (wyartykułowania potrzeb) klienta i je g o różnorodności (w sensie wykorzystania tego samego jednostkow ego produktu przez w'ielu klientów o różnych w ym aganiach i róż

nych warunkach).

Specyfika SI w aspekcie jakości doprowadziła do w ytworzenia szczególnego podejścia do SI, w którym klient płaci nie w iadom o za co (np.

„za użytkowanie produktu”) a dostawca ogranicza zakres gwarancji do... wartości nośników (tj. do ok. I USD lub mniej za CD ROM przy wartości produktu rzędu tysięcy USD).

(26)

18 M arek M iło sz — P o litech n ika L u belska — Jakość systemów informatycznych: między teorią a praktyką

3. Cechy jak ości system ów in form a

tycznych

Cechy opisujące jakość SI, jej parametry czy też kryteria oceny nie są i nie m o g ą być jednorodne. N a SI m ożna bowiem spojrzeć z wielu różnych stron - przekrojów. Inżynieria oprogram owania częściowo porządkuje te przekroje - podobnie ja k w każdym projekcie inżynierskim. Przykładowo, w budownictwie projekt obiektu nie ogranicza się jed y n ie do przedstawienia jego architektury. W je g o skład w chodzą również projekt konstrukcyjny, projekt technologiczny, projekt instalacji ele

ktrycznej, grzewczej, hydraulicznej itp. Każdy z tych elementów oceniany jest przy pom ocy innych kryteriów. Łączna ocena nie jest prostą (czy nawet ważoną) su m ą poszczególnych ocen. Nawet dla tak dobrze zdefiniowanego obszaru ja k budownictwo kom pleksowa ocena

jakości nie je st trywialnym problemem. Każdy SI można przedstawić z różnych stron i wyróżnić w nim (zgodnie z kanonami inży

nierii oprogram owania) struktury: funkcjonal

ną, info rm ac y jn ą oprogramowania, techniczną i przestrzenną. W zasadzie w każdej z tych struktur m ożna zdefiniować specyficzne kryteria jakości.

Kryteria jakości s ą definiowane w wielu metodykach, normach i publikacjach. Defi

nicje te bardzo często są dość zróżnicowane.

Przykładowo model McCalla (wykorzystany notabene ja k o baza w normie ISO 9126) wychodzi z trzech przekrojów jakościowych SI definiowanych z punktu widzenia użytko

wnika: funkcjonowanie systemu, przystosowa

nie do modyfikacji i mobilność oprogram o

wania (rys. 2).

Jakość SI (oprogramowania)

Funkcjonowanie oprogramowania

— Przyjazność

— Bezpieczeństwo

— Wydajność

— Poprawność Niezawodność

Modyfikowalność oprogramowania

— Pielęgnacyjność

— Elastyczność Testował n ość

Mobilność oprogramowania

— Przenośność

— Uniwersalność

— Otwartość

Rys. 2. D rzew o ja k o ś c i wg M cC alla

Ciekawą klasyfikację cech jakości SI zapro

ponowano w [1] - rys. 3. Charakterystyki jakości zostały podzielone na dwie grupy:

funkcjonalne i niefunkcjonalne. W każdej z nich wydzielono dwie podgrupy: widoczne (a więc w j a w n j sposób definiowane) i niewidoczne (tj. takie, które nie są

definiowane, dostrzegane lub określane) przez użytkownika. Taka klasyfikacja pokazuje na istotność całego szeregu cech jakości oprogra

m owania nieznanych użytkownikowi lub nie

m ożliwych do poznania bez ścisłego dostępu do dostawcy SI.

POLSKIE T O W A R Z Y S T W O IN F O R M A T Y C Z N E — O D D Z I A Ł G Ó R N O Ś L Ą SK I

(27)

Jedenasta Górska Szkoła P T I Szczyrk '99^— 21-25 czerwca 1999 ¹⁹

Jakość oprogramowania

i

Cechy Cechy

funkcjonalne niefunkcjonalne

Widoczne przez Ukryte przed Widoczne przez Ukryte przed

użytkownika użytkownikiem użytkownika użytkownikiem

— Funkcjonalność — Jakość modelu danych — Wydajność — P rzenośność

— Samokontrola — Integralność danych — Pojemność — Wydajność

— Odporność na błędy — Testowalność — Interfejs — Bezpieczeństwo

— Raportowanie działań — Gotowość — W spomaganie — Rozszerzalność

— Słownictwo — Dostępność — Konfigurowalność

— Zrozumiałość — Archiwizowalność — Modyfikowalność

— Zabezpieczenia — Możliwość ponownego użycia

Rys. 3. D rzew o ja k o ś c i irg B rinkw ortha

Podobne charakterystyki zdefiniowano w raporcie Narodowego Instytutu Standardów i Technologii Stanów Zjednoczonych - NI ST [14] dla systemów wielokrotnego w ykorzy

stania:

• adaptacyjność,

• efektywność,

• kompletność,

• modu larność,

• niezawodność,

• pielęgnowalność,

• poprawność,

• przenośność,

• zrozumiałość,

• zupełność.

Tamże zdefiniowano cały szereg różnych wskaźników (typu: gęstość błędów, złożoność cyklomatyczna, spójność więzów między- m odułowych czy pokrycie aplikacji testami), które umożliwiają ilościową ocenę poszcze

gólnych cech jakościowych SI.

Bazując na kryteriach jakości (tj. na ich systemie i oszacowanych wartościach) m ożna tworzyć różnego typu modele oceny jakości kompleksowej SI, np. m etodą Q FD (ang.

Q uality Function D eploym ent) [8] czy też stosując metody taksonom iczne [7].

Niezależnie jednak od zastosowanych kryteriów jakości SI ich wartości można ocenić jedynie post factum, tj. po wdrożeniu systemu. Dla klienta, który j u ż zainwestował w system jest to za późno. M etody te nie m ają więc racji bytu w sytuacji produkcji oprogra

mowania na zamówienie - indywidualnego.

Ponadto sam proces w yznaczania całego sze

regu w skaźników jakości SI je s t długotrwały i dość kosztowny. Analizy niektórych syste

m ów m o g ą trwać dłużej niż w ym iana wersji oprogramowania.

4. System y zapew nienia jakości

Jedną z cech charakterystycznych SI jest ograniczona (z punktu widzenia praktyki) możliwość użycia do oceny ich jakości opisa

nych wcześniej metod (wykorzystujących głównie dane statystyczne). Metody te są sze

roko stosowane w procesach produkcji maso

wej. Pozwalają dość dokładnie oszacować poziom jakościow y partii identycznych wyrobów. SI są produktami jednostkow ym i i zamiast szacować liczbę błędnych produktów poprawniej jest nadzorować ich wytwarzanie.

Taka jest idea większości znanych na świecie system ów jakości: am erykański, japoński i europejski. Ten ostatni znany je st ja k o seria norm I S 0 900x. Istnieje specjalny dokument

(28)

2 0 M a re k M iło sz — P olitech n ika L ubelska — Jakość systemów informatycznych: między teorią a praktyki!

dostosowujący normę do specyficznych w ym agań wytwarzania SI ISO 9000-3: „The Application o f ISO 9001 to Software” . N orm y te kom pleksow o traktują proces wytwarzania SI definiując: Quality System Framework, Software Lifecycle i Supporting Activities.

N orm y serii ISO 900x wskazują dość ogólni

kowo drogi osiągania wysokiej jakości pro

duktu końcowego, pewną ideologię zapewnienia jakości i wskazują na konieczność działań na wszystkich etapach cyklu życia SI.

N orm y serii ISO 900x nie zawierają narzędzi do porównania między sobą jakości system ów wytwarzania SI. Takie porównanie możliwe jest d ro g ą ilościowej i kompleksowej oceny wszystkich procesów wytwarzania SI.

Taka ocena w ym aga ustanowienia mierników ilościowych, które pozw olą dość szczegółowo ocenić jakość poszczególnych procesów w y

twarzania i opracować na tej podstawie kom pleksow ą miarę. Próbą stworzenia takiego systemu jest znany model CM M (ang.

C apability M aturity M odel), wprowadzający 5 poziom ów dojrzałości procesów w ytw ór

czych i umożliwiający klasyfikację organizacji wg tego kryterium. Dla organizacji w ytw arza

jących Si bliższa jest mutacja modelu CM M pod n azw ą SE-C M M (ang. System E ngineering C apability M aturity M odel).

Analogiczny system stworzyła European Foundation for Quality Management.

5. M odel EFQ M

EFQM - European Foundation for Quality M anagement (E F Q M ) opracowała w 1991 roku model dla oceny przedsiębiorstw w zakresie wdrożenie Total Quality Management [15], Pozwala on ilościowo ocenić jakość orga

nizacji rozum ianą ja k o satysfakcję klienta, pracowmików i w szerszym rozumieniu - po

zytywny w pływ na całe społeczeństwo. Model EFQM m oże służyć do samooceny firmy, wyszukiwaniu w niej elem entów określających jakość a także służyć do porównania organi

zacji m iędzy sobą - wszystko pod kątem jakości. Pierwotne cele modelu EFQM m ogą być rozszerzone i służyć ja k o narzędzie do porównyw ania dwóch lub więcej przedsię

biorstw' softwarowych. Porównanie to może być niezbędne na etapie np. wyboru ofert firm czy na etapie auditu procesu wytwarzania SI.

Zastosowanie modelu w ym aga oszacowania wartości następujących kryteriów:

1. Działania wprowadzające do kultury jakości (popularyzacja kultury jakości).

2. Misja i strategia działania producentów oprogramowania.

3. Orientacja na klienta wewnętrznego (współpracowników).

4. Zasoby.

5. Procesy.

6. Satysfakcja klientów zewnętrznych.

7. Satysfakcja klienta wewnętrznego.

8. Wpływ organizacji na otoczenie.

9. Rezultaty.

Kiyteria te dotyczą dwóch obszarów: metod i środków (a więc oceny w ysiłków projako- ściowych przedsiębiorstwa) i rezultatów (a więc oceny efektywności działań).

Szczegółowe powiązania pom iędzy kryteria

mi, ich wagi oraz kolejność kwantyfikacji przedstawiono na rys. 4.

Model pozwala odwzorować zachowania i postawy decydentów organizacji oraz ich wpływ na organizację, klientów' i pozostałe elementy otoczenia. Zachowania decydentów oceniane są z punktu widzenia działań prowa

dzonych na rzecz upowszechniania kultury jakości, dostosowania strategii i polityki orga

nizacji do w ym ogów otoczenia i sposobu zarządzania dostępnymi zasobami mediów.

Wszystkie te elementy poprzez procesy decy

zyjne i wytwarzania oddziałują bezpośrednio na klientów i otoczenie, a m iarą tego oddziały

wania są wskaźniki ilościowe, umożliwiające porównanie kilku organizacji.