io 8 z

#%$

(*)*+-,

/102*3*4

576*89051/*:;4

=?>A@

CED

F*G

IKJ-LNM%OQPSRUT1VWXIET*O

YEZ[-\^]

b!c

dfe^gih^j

k-lnmpo%q

rs!tunvwxt

z|{%}~n

n^Ep!

p-|^

^^n

£n¤-£n¥n¦n¤9§A¨

%©¨

©pª

£n«

¬f

¦%®¨

p«

¯K°®p¤9±|

µ|¶n·

º»f¼f¹

»|½

º^¾»

¿º^¶n·

ºÀ

Á;µ|Â-ÃfÄ9Å

ÌÍ|Î

ÏÐÑÒ

ÔÕKÖ×Ø

ÚÛÜKÝÞßxà

â7ãiä

åæ

çè

Zatrudnienie wysokiej klasy specjalistów oraz stosowanie zaawansowanych

narz

dzi wspomagaj

cych nie gwarantuje jeszcze sukcesu projektu; niezb

dne

jest w

ciwe zarz

dzanie przedsi

wzi

ciem

Podstawowe zadania kierownictwa przedsi

wzi

cia programistycznego:

• opracowanie propozycji dotycz

cych sposobu prowadzenia przedsi

wzi

cia,

• kosztorysowanie przedsi

wzi

cia i jego wycena

• planowanie i harmonogramowanie przedsi

wzi

cia,

• monitorowanie i kontrolowanie realizacji przedsi

wzi

cia,

• dobór i ocena personelu,
• opracowanie i prezentowanie sprawozda

dla kierownictwa wy

szego szczebla.

Sposoby zarz

dzania przedsi

wzi

ciem programistycznym w wielu aspektach nie

ró

od zarz

dzania innymi przedsi

wzi

ciami, ale musz

bra

pod uwag

specyfik

procesu budowy oprogramowania (np. nieprzejrzysto

procesu)

ÿ|ý

^ý

;ÿ

"!#$&%'!$&#)(+*'(,#-*

/,0'1,243

1653

:&7-;,<=7)1=8+3

>@?BADCE0F2

Kierownik

programu

Dyrektor d/s

oprogramowania

Kierownik

programu

Kierownik

d/s jako

Kierownik

przedsi

wzi

cia

Koordynator

przedsi

wzi

cia

ze strony klienta

Szef zespo

programistycznego

Szef zespo

programistycznego

Szef zespo

programistycznego

Nie powinien

podlega

kierownikom

programów i

przedsi

wzi

Kierownik

przedsi

wzi

cia

Koordynator

przedsi

wzi

cia

ze strony klienta

O MP

STUR

T V

SWXT

YSMP

SXZ

[ O \]^`_

fg h

ikj&l4mEnoqp6r&sut=vxw&y-z"n{jEo

}@~D}{""

=,)

• Kierownik przedsi

wzi

cia

• Analityk

- osoba bezpo

rednio kontaktuj

ca si

z klientem, której celem jest okre

lenie wymaga

i budowa modelu systemu

• Projektant

- osoba odpowiedzialna za realizacj

oprogramowania; mo

e posiada

wyspecjalizowane funkcje:

– projektant interfejsu u

ytkownika

– projektant bazy danych

• Programista (implementacja)
• Tester (testowanie)
• Twórca dokumentacji u

ytkownika

• Ekspert metodyczny

- osoba szczególnie

dobrze znaj

ca stosowan

metodyk

• Ekspert techniczny

- osoba szczególnie dobrze

znaj

ca sprz

t i narz

dzia

W mniejszych przedsi

wzi

ciach jedna

osoba mo

e pe

wiele funkcji,

sto rozwa

ane s

nast

puj

modele:

•

analityk/projektant + programista:

funkcje analizy i projektu w jednych

kach; zak

ada wysoki poziom

projektanta, natomiast nie wymaga

zbyt wiele od programistów (funkcje

programisty do

¡¢

niskiego poziomu);

w warunkach polskich model nie zdaje

raczej egzaminu

•

analityk + projektant/programista:

model bardziej realistyczny; zak

ada

znacznie wy

szy poziom

przygotowania programisty

¨ ¦©

¬®«

¬°

±¬¦©

¬ ²

³ ¨´µ¶·

½¾¿

À=Á

Â4Ã-ÄÅÇÆ=Á

ÈÊÉ,Ã)ÄFËÌÂ&ÈEÍÎ

Zadaniem szefa nie jest wykonywanie pracy za podleg

ych mu

pracowników, lecz dbanie aby wykonywali oni swoj

prac

; zadaniem

szefa nie jest zmuszanie ludzi do pracy, ale umo

liwienie im tego

ÓÔ

dane cechy kierownika:

•

Zdolno

do przewidywania - umiej

tno

ØÙ

dostrzegania drobnych spraw, które

mog

zal

ÚÛ

kiem powa

niejszych problemów, przewidywania skutków,

podejmowanie zawczasu akcji naprawczych

•

Umiej

tno

Ý-Þ

motywowania - zdolno

ß`à

do pobudzania poczucia przynale

do grupy, zainteresowania wykonywan

prac

, uto

samiania si

z projektem,

atmosfery wspó

pracy w zespole (przywództwo i budowanie zespo

•

Zdolno

ÝÞ

do przystosowania si

do zmieniaj

cej si

sytuacji - umiej

tno

èé

podj

cia niezb

dnych dzia

maj

cych na celu przystosowanie zespo

u i jego

metod pracy do zmienionych warunków

ñ ïò

õö÷ô

ö ø

õùXö

úõïò

õXû

ü ñ ýþÿ

! "

$#% '&()"

,- .

•

Zdolno

/10

do przekonania otoczenia do w

asnych mo

liwo

ci i warto

ci -

kierownik powinien wzbudza

zaufanie; sukces zespo

u zale

y w du

ej mierze od

cech przywódczych szefa i powa

ania i zaufania jakim si

cieszy w

ród cz

onków

grupy

•

Rozpoznawanie i rozwijanie potencja

u swoich wspó

pracowników -

naturalnym zjawiskiem jest wymiana personelu (np. dobrze wyszkoleni i

kompetentni pracownicy awansuj

;

lub zmieniaj

;

prac

); powstaje potrzeba

wprowadzania do zespo

u nowych ludzi, w

ciwego ich szkolenia, pomocy w

rozwijaniu ich potencja

•

Komunikatywno

4=<

atwo

komunikownia si

z szerokim wachlarzem ludzi -

podw

adni, kierownictwo, klienci, dostawcy, ...

•

Terminowe podejmowanie decyzji dostosowanych do bie

cej sytuacji i

potrzeb - kierownik powinien precyzyjnie okre

co ma by

zrobione i w jakim

terminie; wi

;

e si

to cz

sto z podejmowaniem decyzji w sytuacji niepe

nej

wiedzy.

B@1C

FHGJIJE

FMLNG

OPFM@1C

FNQ

RNBJS1TMUWV

[

] ^`_

acb%de$f)g

hiejNkle

hm'nop

Struktura sieciowa - ka

dy komunikuje si

i wspó

pracuje z pozosta

ymi

(nie powinna by

zbyt liczna); zespo

y o podobnym do

wiadczeniu i

stopniu zaawansowania; zalety:

• dzi

cis

ej wspó

pracy cz

onkowie zespo

u wzajemnie kontroluj

swoj

prac

; szybko osi

gane s

standardy jako

• umo

liwia realizacj

idei wspólnego programowania

• poniewa

praca cz

onków zespo

u jest znana dla innych cz

onków,

atwo mog

oni przej

x`v

obowi

zki pracownika, który opu

zespó

Struktura gwia

dzista - szef zespo

u jest jedyn

{

osob

{

wspó

pracuj

{

z pozosta

ymi osobami; przydziela zadania i kontroluje

efekty; komunikacja pomi

}

dzy cz

onkami zespo

u poprzez szefa; jest

przydatna wtedy, gdy w sk

ad zespo

u wchodzi wielu

niedo

wiadczonych pracowników; wielko

zespo

u mo

e by

znacznie

}

ksza ni

w strukturze sieciowej (ogranicza j

{

jedynie zdolno

szefa

do równoczesnego kierowania du

{

grup

{

); najpowa

niejsz

{

wad

{

jest

trudno

zast

{

pienia szefa w momencie jego odej

cia

HJJ

PM1

NWJ

¡ ¢£¤ H¢¡=¥§¦¨¡%©ª¨«

¬iª¥¤®H

Zespó

programisty wiod

cego:

• programista wiod

(wybitne kwalifikacje):

– wymy

la koncepcj

i specyfikuje zadania

– sam realizuje najwa

niejsze zadania

– przydziela zadania puli specjalistów

• zast

pca (dobrze wykwalifikowana osoba)

– na bie

co, biernie uczestniczy w pracy

szefa (w ka

dej chwili mo

e go zast

)

– mo

e przygotowywa

testy

• bibliotekarz/sekretarz

- odpowiada za

dokumentacj

i komunikacj

w zespole

Testerzy

Zespó

internetowy

Zespó

baz danych

Analitycy

Zespó

kompetencyjny

Projekt

1.5

3
1

0.5

2
1

Programista

wiod

Zast

pca Bibliotekarz

/sekretarz

Zespó

programisty wiod

cego

Pula specjalistów

Struktura macierzowa
• specjali

ci pogrupowani w zespo

y kom-

petencyjne i przydzielani do wykonania

konkretnych zada

w ramach projektów

• ekonomiczne wykorzystanie zasobów

ludzkich

• podstawowa wada: dwupodleg

¾Á

(szef

zespo

u i szef projektu)

ÅÃ1Æ

ÉHÊJËJÈ

ÊÌ

ÉMÍNÊ

ÎPÉMÃ1Æ

ÉNÏ

ÐNÅJÑ1ÒMÓWÔ

Ú Û`Ü

ÝÞ

ßà

áâ$ãäæåäåçè

è$ã¨é

äêlâ

Þ¨ë$êlÞ'ì)ê%â¨í(Þ'îïâã¨é

•

Umiej

tno

pracy w stresie

- w procesie budowy i konserwacji

oprogramowania cz

sto zdarzaj

okresy wymagaj

ce szybkiego wykonania

onych zada

; dla wi

kszo

ci osób niewielki stres dzia

a mobilizuj

co, ale po

przekroczeniu pewnego progu nast

puje spadek mo

liwo

ci danej osoby (próg

ten jest bardzo ró

ny dla ró

nych osób); nale

y pami

e w stresie nie

pracuje si

lepiej a jedynie szybciej.

•

Zdolno

ci adaptacyjne

- informatyka jest jedn

z najszybciej zmieniaj

cych

dziedzin; ocenia si

e 7-9 miesi

cy przynosi w informatyce zmiany, które w

innych bardziej tradycyjnych dziedzinach zajmuj

5-7 lat; narzuca to konieczno

øWù

sta

ego dokszta

cania si

(poznawanie nowych narz

dzi, sprz

tu,

oprogramowania, technologii, metod, sposobów pracy), gdy

stosunkowo szybko

na „wypa

ø`ù

z gry o najwy

sze stawki”(u

pienie - zajmowanie si

jednym

problemem w jednym

rodowisku przez lata mo

e mie

nieprzyjemne

konsekwencje); z drugiej strony wiele osób nie wytrzymuje zawrotnego tempa

(tzw. wypalanie si

osób)

þü1ÿ

ü1ÿ

!#"%$'&")(+*

,.-/*

0.132.46587:9<;>=:?%@A2B1DC

Czynniki psychologiczne maj

zasadniczy wp

yw na efektywno

pracy zespo

Wyró

nia si

nast

puj

ce typy osób:

•

Zorientowani na zadanie (ang. task-oriented)

- osoby samowystarczalne,

zdolne, zamkni

te, agresywne, lubi

ce wspó

zawodnictwo, niezale

ne; s

zwykle

efektywne, o ile pracuj

w pojedynk

, natomiast zespó

ony tylko z takich osób

e by

jednak nieefektywny (zbyt wiele indywidualno

ci - rywalizacja); je

li nie s

doceniani mog

przeorientowa

na siebie

•

Zorientowani na siebie (ang. self-oriented)

- osoby niezgodne, dogmatyczne,

agresywne, zamkni

te, lubi

ce wspó

zawodnictwo, zazdrosne; mog

efektywne w

zespole pod warunkiem odpowiedniego motywowania przez kierownictwo

•

Zorientowani na interakcj

(ang. interaction-oriented)

- osoby nieagresywne, o

niewielkiej potrzebie autonomii i indywidualnych osi

gni

, pomocne, przyjazne;

zespo

y z

one z tego typu osób pracuj

najefektywniej; szczególnie potrzebni we

wst

pnych fazach projektu podczas kontaktów z klientami

USWV

Z[\Y

[]

Z ^_[

` Z SWV

Z_a

b_UcWd ef

lnmo

p%qsrut/vBtDwyx

z|{.q6zB}~

• Zamiast du

ej hali („ameryka

skie biuro”), lepsze wyniki daje umieszczenia 2-3

stanowisk pracy w wielu mniejszych pomieszczeniach

• Umo

liwienie personalizacji stanowiska pracy

• Zdrowe stanowisko pracy (prawid

owe o

wietlenie - okna, ...)

• Pokój zebra

dla organizowania formalnych spotka

pracowników; zakaz

dyskusji w pokojach pracy

• Miejsce dla spo

ywania posi

ków, przerw relaksuj

cych w pracy, spotka

nieformalnych (np. omówienie spraw przy kawie)

• Poczucie pracy na nowoczesnym sprz

cie (wydajno

i ch

ludzi do pracy

gwa

townie spada, je

eli odczuwaj

oni,

e pracuj

na przestarza

ym sprz

cie -

nawet wtedy, gdy wymiana sprz

tu jest merytorycznie nieuzasadniona)

• Komfort psychiczny, w

ciwa atmosfera w pracy, eliminacja napi

i zadra

nie

nie dopuszczanie do rozmycia odpowiedzialno

ci, sprawiedliwa ocena wyników

pracy poszczególnych cz

onków zespo

u, równomierny rozk

ad zada

¢#£.¤ ¥§¦.¨%¦u©/¤s£ª¥§¦B«¬£.¨/

®|¯u¤s°:®8±ª²³

«µ°)

adanie planu realizacji przedsi

wzi

cia polega na:

•

ustaleniu kalendarza prac:

– daty rozpocz

cia przedsi

wzi

cia

– dni roboczych i wolnych w przewidywanym okresie realizacji przedsi

wzi

cia

– czasu pracy w poszczególnych dniach

• podziale przedsi

wzi

cia na poszczególne zadania,

• okre

lenie parametrów zada

• okre

lenie zasobów niezb

dnych do realizacji poszczególnych zada

• ustaleniu dost

pno

ci zasobów,

• ustaleniu kolejno

ci i czasów wykonania poszczególnych zada

Przedsi

wzi

cie powinno by

podzielone na stosunkowo ma

e zadania (realizacja

do kilku dni), których parametry mo

atwo okre

; harmonogramowanie

na wykonywa

z ró

nym stopniem dok

adno

ci (najbli

sze zadania

szczegó

owo; pó

niejsze bardziej ogólnie)

ÄÂWÅ

ÈÉÊÇ

ÉË

È Ì_É

Í È ÂWÅ

È_Î

Ï_ÄÐWÑ ÒÓ

ØÙ

ÚnÙÛ

Ü#ÝuÞ ß§àªáBàuâ/ÞsÝ/ß§à8ãäÝuá/å

è6é

Po ustaleniu zada

konieczne jest okre

lenie parametrów czasowych:

• czasu wykonania,
• najwcze

niejszy mo

liwy termin rozpocz

cia (np. niezb

dne s

pewne dane, które mog

dostarczone dopiero ...),

• po

íï

dany czas zako

czenia,

oraz innych ogranicze

kolejno

ci wykonywania prac (np. aby rozpocz

òWó

nowe

zadanie niezb

dne jest zako

czenie pewnych innych zada

); mo

wykorzysta

do tego diagramy typu PERT

Pewne zadania mog

zosta

opó

nione bez wp

ywu na termin zako

czenia ca

ego

przedsi

wzi

cia, inne natomiast tzw. zadania krytyczne nie mog

zosta

opó

nione; ich ci

g definiuj

cy termin zako

czenia nazywany jest

cie

krytyczn

adaj

c harmonogram nale

y bra

pod uwag

dost

pno

zasobów niezb

dnych

do realizacji poszczególnych zada

ównie zasoby ludzkie, ale mo

e by

równie

sprz

t i oprogramowanie)

ûùWü

ÿ ùWü

!"#%$'&(

)

Monitorowanie polega na

ledzeniu przebiegu realizacji przedsi

wzi

cia oraz

reagowaniu na pojawiaj

ce si

problemy; nast

puj

ce czynno

ci:

• obserwacja rzeczywistych terminów rozpocz

cia i zako

czenia zada

oraz

porównywanie ich z zaplanowanymi,

• identyfikacja przyczyn niezgodno

ci z planem,

• modyfikacja harmonogramu, je

eli ró

nice pomi

dzy harmonogramem a

rzeczywistym przebiegiem realizacji s

zbyt du

• obserwacja wykorzystania zasobów oraz rozstrzyganie konfliktów zasobowych,
• przesuwanie zasobów pomi

dzy zadaniami oraz przedsi

wzi

ciami.

Szczególn

uwag

nale

y zwraca

na zadania krytyczne i na zadania ze

stosunkowo niewielkim luzem

785:9

;

=>?<

>8@

=BAC>

DE=B5:9

=CF

GC7H:IBJ K

RTSU

V%WYXZ%X[]\

^Y_YZa`

bacYda`(WYe#f

_h\

bkj

ZaX

mon

pEn

qrts

• O ile celem in

ynierii oprogramowania jest tworzenie dobrego oprogramowania,

o tyle celem firmy programistycznej jest po prostu zarabianie pieni

dzy

• Jako

produktu jest tylko jednym z czynników wp

ywaj

cych na wynik

ekonomiczny firmy; inne istotne aspekty:

– reklama i promocja produktu,
– renoma i zaufanie do producenta,
– rodzaj i zakres gwarancji oraz innych us

{

ug dla klientów,

– przyzwyczajenia klientów,
– sposób wyceny rozmaitych wersji produktu,
– sposób rozwoju produktu, polityka uaktualnie

– efektywno

}8~

sposóbu pozyskiwania klientów lub dystrybucji produktu.

• Czynniki te pozwalaj

redukowa

yw ni

szej jako

ci produktów danej firmy;

wydaje si

jednak,

e wiele firm zwraca zbyt wielk

uwag

na dzia

alno

marketingow

zaniedbuj

c kwestie podstawowe

EB:

((

¡n(r]n

¢£q s

¤¥so(¢Y¦¨§%

m©n

Wydajno

Warto

Koszt

Jako

Ilo

}8~

Personel

Zasoby

{

ono

Niezawodno

Defekty

Wielko

Funkcjonalno

Czas

Pieni

dze

Sprz

Oprogramowanie

Ograniczenia

}

rodowiskowe

Trudno

problemu

Czynniki

{

ywaj

na ogóln

wydajno

Myl

ce, wr

cz niebezpieczne jest zast

powanie wielu miar

jedn

miar

, np. d

ugo

wyprodukowanego kodu

EB:

C:B

®°¯a±³²£´µ

¶oµ³·¹¸¹ºa±Y»%¼½º%´µ

º¾´aº£¶

ºaÀ(Á%¼ÃÂ(ÄÅºo±¹Æ

• Modele algorytmiczne

- opis przedsi

wzi

cia za pomoc

charakteryzuj

cych go

atrybutów (liczbowych) i na tej bazie wyliczenie (np. prosta formu

a matematyczna)

nak

adów

• Ocena przez ekspertów

- bazuj

na w

asnym do

wiadczeniu zdobytym przy

realizacji innych projektów

• Ocena przez analogi

- przy za

eniu gromadzenia informacji o uprzednio

wykonanych projektach; wyszukuje si

podobne systemy poprzednio zrealizowane i

wykorzystuje nak

ady poniesione na ich stworzenie

• Wycena dla wygranej (ang. pricing to win)

- na podstawie oceny mo

liwo

klienta oraz przewidywanych dzia

konkurencji; opiera si

na prawie Parkinsona -

przedsi

wzi

cia s

wykonywane przy za

onych kosztach (jakie by one nie by

• Szacowanie wst

puj

- dzieli si

przedsi

wzi

cie na mniejsze zadania, które

atwiej oszacowa

; koszt ca

ci jest ich sum

(ew. z narzutem na integracj

)

Ó8Ñ:Ô

×ØÙÖ

Ø8Ú

×BÛØ

ÜE×BÑ:Ô

×Ý

ÞCÓ8ß àáâ

çá

èéê

ë»(À(¯ì

¯íºì

î£»kÄïÆ©ðEñ]µ

±Y¸Y´a¯ò·¹¸¹ºa±Y»o¼óº(´µ

º¾´oº£¶

ºaÀ(Á%¼

• Wi

kszo

õö

modeli przyjmuje,

e jednym z istotnych atrybutów jest rozmiar

systemu, mierzony np. liczb

instrukcji (linii) kodu (ang. Lines Of Code - LOC),

KLOC (ang. Kilo-LOC), KDSI (ang. Kilo (thousand) of Delivered Source code

Instructions)

• Specjalizacja metryk w kierunku konkretnej klasy oprogramowania powinna

dawa

lepsze i bardziej adekwatne oceny ni

metryki uniwersalne

• Najlepiej jest stosowa

zestawy metryk, co pozwala zmniejszy

dy pomiaru

• Metryki powinny by

wykorzystywane jako metody wspomagania ekspertów

(stosowane formalistycznie mog

gro

ne)

• Pomimo pochodzenia empirycznego, metryki skutecznie pomagaj

w szybkiej i

mniej subiektywnej ocenie oprogramowania

•

adna metoda przewidywania kosztów nie jest doskona

a i jest oparta na

szeregu arbitralnych za

; niemniej dla celów planowania tego rodzaju

metody staj

si konieczno

#%$'&

(*),+%-/./02143*5/67+ 8:9<;=+>

?,)21@3A67+A(B3C./)ED

GHIG H=JKHMLONQP

Powsta

a w oparciu o dane z rzeczywistych projektów, realizowanych

tradycyjnie (np. bez narz

dzi CASE) w oparciu o model kaskadowy, autor

Boehm, 1981 r.

Wymaga oszacowania liczby instrukcji, z których b

dzie sk

ada

system

(co mo

e by

tak samo trudne jak oszacowanie nak

adów)

Wyró

nia si

trzy klasy przedsi

wzi

SVU

•

atwe (ang. organic)

- wykonywane przez stosunkowo ma

e zespo

y, z

one z osób o

podobnych wysokich kwalifikacjach; dziedzina oraz wykorzystywane metody i narz

dzia

[

dobrze znane

•

rednie (ang. semi-detached)

- cz

onkowie zespo

u ró

[

stopniem

zaawansowania; pewne aspekty dziedziny problemu lub wykorzystywane narz

dzia nie

[

dobrze znane

•

Trudne (osadzone, ang. embedded)

- przedsi

wzi

cia realizuj

[

ce systemy o bardzo

onych wymaganiach; dziedzina problemu, stosowane narz

dzia i metody mog

[

]

ej mierze nieznane; cz

onkowie zespo

u nie maj

[

wiadczenia w realizacji

podobnych zada

cad

g hif

gklh

mgad

gln

ocpqr's

x'y

z:{|x

}~/%~B~//4A@B

KDSI

Nak

atwe

trudne

rednie

• Podstawowy wzór dla oszacowania

nak

adów w osobomiesi

cach

(zale

wyk

adnicza):

¡/¢¤£¦¥¨§ª©

• K oznacza rozmiar kodu

ród

owego

mierzony w tysi

cach linii (KDSI); nie

obejmuje kodu, który nie zosta

wykorzystany w systemie

• Warto

ci sta

ych A i b zale

od klasy,

do której zaliczono przedsi

wzi

cie

• Dla niewielkich przedsi

wzi

±'²

zale

ci bliskie liniowym; wzrost jest

szczególnie szybki dla przedsi

wzi

±²

trudnych (du

y rozmiar kodu)

Przedsi

wzi

cie

atwe:

µ·¶¹¸

»·¼¾½

¿·À

ÂÄÃ

ÅOÆ

Ç È

Przedsi

wzi

cie po

rednie:

Ë·Ì¹Í

Ï·Ð¾Ñ

Ò·Ó

ÕÄÖ

×OØ

×QÙ

Przedsi

wzi

cie trudne:

Û·Ü¹Ý

Ü·ß¾à

á·â

äÄå

æOç

è é

íîï

ò óôñ

óõ

òöó

÷òîï

òø

ùíúûüý

• Znaj

c nak

ad mo

na oszacowa

czas

(w miesi

cach) realizacji, z czego

wynika przybli

ona wielko

&('

zespo

)

• Z obserwacji wiadomo,

e dla ka

dego

przedsi

wzi

cia istnieje optymalna

liczba cz

onków zespo

u wykonawców

• Zwi

kszenie tej liczby mo

e nawet

wyd

czas realizacji

Przedsi

wzi

cie

atwe:

/10(2436587:9

;=<6>?2?@

BDC

EGF

Przedsi

wzi

cie po

rednie:

L1M(N4O6P8Q:R

S=T6U?N?V

NDX

YGZ

Przedsi

]

wzi

]

cie trudne:

^1_(`4a6b8c:d

e=f6g?`?h

`Dj

kGl

Otrzymane w ten sposób oszacowania powinny

skorygowane przy pomocy tzw.

czynników modyfikuj

cych

Atrybuty przedsi

wzi

cia brane pod uwag

• wymagania wobec niezawodno

ci systemu

• rozmiar bazy danych w stosunku do

rozmiaru kodu

• z

ono

r(o

systemu (z

ono

ruo

struktur

danych i algorytmów, komunikacja z innymi

systemami, stosowanie obl. równoleg

ych)

• wymagania co do wydajno

ci systemu

• ograniczenia pami

• zmienno

r(o

sprz

tu i oprogramowania

systemowego tworz

cego

rodowisko pracy

systemu

yuw{z

}

~:((}

}

4~w{z

?yu(

¢¡£¡£¤£

• Liczba linii kodu jest znana dok

adnie dopiero wtedy, gdy system jest napisany a

szacunki mog

(i zwykle s

) obarczone bardzo powa

nym b

dem

(niekiedy ponad 100%)

• Okre

lenie “linii kodu

ród

owego” inaczej wygl

da dla ka

dego j

zyka

programowania (np. 1 linia w Smalltalk’u jest równowa

na 10-ciu linii w C; dla

zyków 4GL ten stosunek mo

e by

nawet 1000:1)

• Koncepcja oparta na liniach kodu

ród

owego natomiast ca

kowicie nie przystaje

do wspó

czesnych narz

dzi programistycznych, np. opartych o programowanie

wizyjne

• Opiera si

tylko na d

ugo

ci kodu i nie bierze w ogóle pod uwag

funkcjonalno

ci ani z

ono

ci produktu

• Kwalifikacja przedsi

wzi

cia do predefiniowanych klas oraz dobór czynników

modyfikuj

cych jest trudny, a ewentualne b

dy mog

prowadzi

do znacznych

rozbie

ci pomi

dzy oczekiwanym i rzeczywistym kosztem

·uµ{¸

»:¼(½(º

¼u¾

»¿?¼

À4»µ{¸

»?Á

Â?·(Ã{ÄÅÆ

Ë Ì

ÍÌ Ë

Î8ÏÐÑ

ÓÔÐÕÖ×ÏÙØ1ÚÛ=ÜÞÝ6Ö×Ï×ØàßÔá1â:Ïãáßåä

• Metoda analizy punktów funkcyjnych (ang. functional points - FP), zosta

opracowana przez Albrechta;

czy ona w

asno

ci metody, badaj

cej rozmiar

projektu programu z mo

liwo

ciami metody badaj

cej produkt programowy

(jego funkcjonalno

èê

)

ëíìïîðãëíìòñ

ëíìïîðãëíìóñõô÷öóë

ô÷öóë

Liczb

pierwotn

punktów funkcyjnych (UFP) wylicza si

korzystaj

c z

nast

puj

cych danych:

• Wej

cia u

ytkownika: obiekty wej

ciowe wp

ywaj

cych na dane w systemie

• Wyj

cia u

ytkownika: obiekty wyj

ciowe zwi

zane z danymi w systemie

• Zbiory danych wewn

trzne: liczba wewn

trznych plików roboczych

• Zbiory danych zewn

trzne: liczba plików zewn

trznych zape

nianych przez produkt

programowy

• Zapytania zewn

trzne: interfejsy z otoczeniem programu

"$#%

&('

)+*-,/.10 21)

3(4+57698;:=<$4+5+6?>@:9A 51B

Czynnik z

ono

Wej

cia u

ytkownika (I)

Wyj

cia u

ytkownika (O)

Zbiory danych wewn

trzne (l)

Zbiory danych zewn

trzne (E)

Zapytania zewn

trzne (F)

Prosty

3
4
7
5
3

redni

4
5

7
4

ony

6
7

15
10

Wagi przypisywane elementom zale

od ich typu

NPORQ/SUT

NVORQWSUT

Y[Z

YRZ

]U^

`Ra

bUc

eRf

gUh

j[k

jRk

lUm

gdzie w

- wagi czynników, e

- liczno

ci elementów

usv

y z{x

y}z

~ysv

?R(7

¡V¢¤£¥1¡§¦7¨7¢

TCF - liczba ustalana na podstawie

ywu 14 czynników

(0.65<=TCF<=1.35 ):

• wyst

powanie urz

dze

komunikacyjnych

• rozproszenie przetwarzania
• d

ugo

¸¹

czasu oczekiwania na odpowied

systemu

• stopie

obci

¼½

enia sprz

tu istniej

cego

• cz

stotliwo

¿À

wykonywania du

ych

transakcji

• wprowadzanie danych w trybie

bezpo

rednim

• wydajno

¿À

ytkownika ko

cowego

• aktualizacja danych w trybie

bezpo

rednim

• z

ono

¿À

przetwarzania danych

• mo

liwo

¿À

ponownego u

ycia

programów w innych

zastosowaniach

•

atwo

¿À

instalacji

•

atwo

¿À

obs

ugi systemu

• rozproszenie terytorialne
•

atwo

¿À

wprowadzania zmian -

piel

gnowania systemu

ÅÃÆ

É ÊËÈ

ÊÌ

ÉÍÊ

ÎÉÃÆ

ÉÏ

ÐÅÑÒÓÔ

ÙÚ

Û$Ü%Ù

ÝßÞ(à?áâ-ãäÞ1åRæ$ç(èé

êUë+ì+è(à¤æîíªïñð$ì7è+à?ò@Þ9óôèVÞVò§õ

• Ocena z

ono

ci realizacji systemów

• Audyt projektów
• Wybór systemów informatycznych

funkcjonuj

cych w przedsi

biorstwie do

rein

ynierii (wg. koszt utrzymania/FPs)

• Szacowanie liczby testów
• Ocena jako

ci pracy i wydajno

ci zespo

ów

ludzkich

• Ocena stopnia zmian, wprowadzanych przez

ytkownika na poszczególnych etapach

budowy systemu informatycznego

• Prognozowanie kosztów piel

gnacji

i rozwoju systemów

• Porównanie i ocena ró

nych ofert dostawców

oprogramowania pod k

tem merytorycznym i

kosztowym

1 FP

≈ 125 instrukcji w C

10 FPs - typowy ma

y program

tworzony samodzielnie przez

klienta (1 m-c)

100 FPs - wi

kszo

øû

popularnych

aplikacji; warto

øû

typowa dla

aplikacji tworzonych przez klienta

samodzielnie (6 m-cy)

1,000 FPs - komercyjne aplikacje w

MS Windows, ma

e aplikacje klient-

serwer (10 osób, ponad 12 m-cy)

10,000 FPs - systemy (100 osób,

ponad 18 m-cy)

100,000 FPs - MS Windows’95, MVS,

systemy militarne

ÿý

!#"%$'&)(+*-,/.%0

12&)(3,#451

• Alternatywna metoda w stosunku do punktów funkcyjnych

zaproponowana na pocz

tku lat 90-tych przez Bankera i wspó

• Wykorzystywana do j

zyków programowania baz danych, 4GL

– obiektowe w nazwie nie ma tutaj zwi

zku z programowaniem obiektowym

• Liczba punktów obiektowych jest wa

;

sum

;

– liczby ró

nych formatek ekranowych (prosty ekran - 1 punkt,

redno z

ony - 2

punkty, bardzo z

ony - 3 punkty)

– liczba generowanych raportów (prosty raport - 2 punkty,

rednio skomplikowany -

5 punktów, a potencjalnie najtrudniejsze do utworzenia - 8 p.)

– liczba modu

ów w j

zykach 3GL (takich jak C++; Java) , które nale

y utworzy

celu uzupe

nienia kodu 4GL - ka

dy modu

10 punktów

• Zalet

;

punktów obiektowych w porównaniu z punktami fukcyjnymi jest

to,

atwiej je obliczy

na podstawie specyfikacji oprogramowania

wysokiego poziomu

F DG

JKLI

K M

JNOK

PJDG

JOQ

R F STU V

[ U

\3]^[

_a`ab

cedgfihj'k/l

`mconp`qhsr+f'tuj

w xzys{

|}~z

x3|O)z

w})u

• Wiele zamierze

zwi

zanych z metrykami oprogramowania zawiod

gdy

cele by

y zwykle s

abo zdefiniowane; aby temu przeciwdzia

Uniwersytecie Maryland (Vic Basili et al.) opracowano metod

GQM

• Trzy podstawowe kroki:

– ustalenie celów w kategoriach zamiaru, perspektywy i

rodowiska

– ponowne wypowiedzenie celów w terminach opowiedzi na

atwe do

“skwantyfikowania” pytania

– okre

lenie metryk i danych, które nale

y zgromadzi

, aby udzieli

odpowiedzi na

postawione pytania

• Dzi

ki takiemu u

eniu koncentrujemy si

tylko na metrykach, które

odnosz

do interesuj

cego nas celu

• Klika pomiarów, aby odpowiedzie

na jedno pytanie; pojedynczy

pomiar mo

e mie

zastosowanie do kilku pyta

¡ ¢

¥¦§¤

¦ ¨

¥© ¦

ª¥¢

¥ «

¬ ¡®¯°

µ ¶

·¸ µ

¹#ºz»¼2½

¿qÀÂÁÄÃ2ÅuÆ%ÇzÈÃ#ÉËÊz¿'Ì/Í

¿ÏÎeÐ5Ñ

Oceni

skuteczno

Ó+Ò

narz

dzia ‘X’

Kto u

ywa

narz

dzia ‘X’ ?

Jaka jest wydajno

×Ø

programisty?

Jaka jest

jako

×Ø

kodu?

CEL:

PYTANIA:

METRYKI:

Odsetek

programistów

wiadczenie

programistów:

- lata pracy

- miesi

stosowania ‘X’

Wielko

×Ø

kodu:

- KLOC

- FP

- ....

Nak

pracy

Defekty

...

Þ Üß

âãäá

ã å

âæOã

çâÜß

âOè

é Þ êëì í

ò ó

ô3ò^õ

öø÷gùsúzûü

Niedojrza

Dojrza

Improwizacja podczas procesu

wytwórczego

Proces jest wyspecyfikowany, ale

specyfikacja nie jest stosowana

Dora

ne reagowanie w sytuacji

kryzysów

Harmonogram i bud

et s

przekraczane

Funkcjonalno

%'&

jest stopniowo

okrajana

Jako

%'&

produktu jest niska

Brak obiektywnych kryteriów oceny

(

Zdolno

)'*

do budowy

oprogramowania jest cech

organizacji a nie personelu

(

Proces jest zdefiniowany, znany i

wykorzystywany

(

Proces jest obserwowany i

ulepszany

(

Prace s

planowane i monitorowane

(

Role i odpowiedzialno

)

ci s

zdefiniowane

(

Obiektywna, ilo

)

ciowa ocena

/0-21

576'8'4

609

5;:<6

=>5;-21

5<?

@</'A2B;CED

JLK

MNJPO

QSRTUWVTRYX[Z\^]

cde fghikjlnmNjodfpqg re

• Model dojrza

ci procesu wytwórczego (ang. Capability Maturity Model -

CMM) zosta

opracowany w latach 80-tych przez ameryka

ski Instytut

ynierii Oprogramowania na zlecenie rz

du USA

• Wykorzystywany by

w procedurach oceny (klasyfikacji) potencjalnych

wykonawców oprogramowania dla Departamentu Obrony

• Opiera si

w znacznym stopniu na koncepcjach TQM (ang. Total Quality

Management)

• Ocenia wiele ró

nych atrybutów wytwarzania oprogramowania, obejmuj

cych

ycie narz

dzi i standardowych praktyk

• Model ten szybko zyska

szerok

akceptacj

jako wzorzec do usprawniania

procesu programowania

• Wywar

znaczny wp

yw na u

wiadomienie znaczenia miar i ich stosowanie,

gdy

w CMM miary s

uwa

ane za wa

ne dla osi

gni

cia wy

szych

poziomów usprawnienia procesu

{

}

~0|2

7''

;

>;|2

<~0E'P

¡ Y¢[£^¤

§¨©nª¨¬«£§« ¨

Wyró

niono 5 poziomów dojrza

ci wytwórców (poczynaj

c od p. najni

szego):

• pocz

tkowy (1) - proces chaotyczny, nie istniej

adne standardy, decyzje podejmowane

ad hoc; mo

e dotyczy

nawet firm o dobrym zaawansowaniu technicznym

• powtarzalny (2) - proces zindywidualizowany;przedsi

wzi

cia wykonywane w podobny

sposób (standardy de facto); standardy nie s

udokumentowane i nie istniej

cis

procedury kontroli

• zdefiniowany (3) - proces zinstytucjonalizowany; standardy post

powania s

zdefiniowane, sformalizowane i ich stosowanie jest kontrolowane

• zarz

dzany (4) - proces nie tylko podlega kontroli ale jest równie

mierzony w sposób

ilo

ciowy; informacje zwrotne wykorzystywane s

do sterowania procesem

• optymalizuj

cy (5) - standardy s

gle uaktualniane; informacje zwrotne wp

ywaj

ulepszenie procesu; standardy zawieraj

elementy pozwalaj

ce na dostrojenie procesu

do aktualnych potrzeb

Niewiele firm uzyska

o poziom 3-ci, umo

liwiaj

cy dostarczanie oprogr. dla Dep.

Obrony; tylko IBM w zakresie oprogr. promu kosmicznego dla NASA uzyska

poziom 5-ty

Wyszukiwarka

Podobne podstrony:
IO ALL
io wyk5
gprs t6 io pl 1013
BD IO 3
IO zerówka opracowanie
aqua s io pl 1109
cz emm2 io pl 0407
acx201 io pl 1112
amd101 io pl 0510(2)
io w11 zasady projektowania opr
dok5, Prywatne, WAT, SEMESTR IV, IO, Zaliczenie IO
graphite io pl 1109
io 5 z
aqua pro io pl 1109
MELFA IO
IO wsp, TutorialJava
MCR II BIC IO
IO wprowadzenie

więcej podobnych podstron