Engenharia de Software Wilson de Padua Paulo Filho

W WILSON ILSON DE DE P PDUA DUA P PAULA AULA F FILHO ILHO
E
E
NGENHARIA
NGENHARIA
DE
DE
S
S
OFTWARE
OFTWARE
FUNDAMENTOS, MTODOS E PADRES
LTC Livros Tcnicos e Cientficos Editora S.A.
2001
Engenharia de Software Fundamentos, Mtodos e Padres - Wilson de Pdua Paula Filho
1
1
CAPTULO 1 ENGENHARIA DE SOFTWARE
1 NATUREZA
1.1 Engen!"#! $e S%&'(!"e e C#)n*#! $! C%+,-'!./%
O que Engenharia de software?
A informtica definida como uma cincia cujo assunto o
processamento de informao atravs de mquinas. A cincia por sua ve! tem
como foco a cumu"ao do conhecimento atravs do mtodo cient#fico gera"mente
$aseado em e%perimentos e o$serva&es.
A Engenharia de 'oftware no se confunde com a (incia da
(omputao e nem uma discip"ina desta ta" como a Engenharia )eta"*rgica no
uma discip"ina da +#sica dos )etais nem a Engenharia E"trica uma discip"ina da
+#sica da E"etricidade. (omo toda engenharia a Engenharia de 'oftware usa
resu"tados da cincia e fornece pro$"emas para estudo desta, mas so voca&es
profissionais comp"etamente distintas to distintas quanto as voca&es do
engenheiro e do f#sico do mdico e do $i-"ogo do po"#tico e do cientista po"#tico.
1.0 S#1'e+!1 $e #n&%"+2'#*!
As mquinas de tratamento de informao so organi!adas em
estruturas *teis formando os sistemas de informtica. .rias defini&es de sistema
so aqui pertinentes.
/0 (onjunto de e"ementos materiais ou ideais entre os quais se
possa encontrar ou definir a"guma re"ao
10 2isposio das partes ou dos e"ementos de um todo coordenados
entre si e que funcionam como estrutura organi!ada
30 4eunio de e"ementos naturais da mesma espcie que constituem
um conjunto intimamente re"acionado.
O software a parte programve" de um sistema de informtica. E"e
um e"emento centra", rea"i!a estruturas comp"e%as e f"e%#veis que tra!em fun&es
uti"idade e va"or ao sistema. )as outros componentes so indispensveis, as
p"ataformas de hardware os recursos de comunicao de informao os
documentos de diversas nature!as as $ases de dados e at os procedimentos
manuais que se integram aos automati!ados.
0 PRODUTOS
0.1 P"%34e+!1
)uitas pessoas inc"usive dirigentes de empresa perce$em o
computador como pro$"ema e no como so"uo. )uitos aceitam como fato da vida
que os sistemas de informtica,
- no faam o que deveriam fa!er5
- sejam caros5
- sejam entregues tarde demais5
2
2
- sejam de $ai%a qua"idade cheios de defeitos dif#ceis de usar
sejam "entos etc.
A tecno"ogia s- reso"ve pro$"emas quando usada por pessoas
qua"ificadas dentro de processos adequados. Os sistemas de informtica so
produtos da tecno"ogia de tratamento da informao. Os pro$"emas que ocorrem
com sistemas de informtica podem ter vrias causas,
- 6odem ser fruto de deficincia de qua"ificao das pessoas que os
operam seja por fa"ta de treinamento dificu"dade de uso do pr-prio
sistema ou outros fatores.
- 6odem originar7se de processos de neg-cio inadequados.
- 6odem tam$m ser causados por deficincias de tecno"ogia ou
seja do pr-prio sistema de informtica.
0.0 P"%$-./%
0.0.1 C#*4%1 $e 5#$!
A Engenharia de 'oftware se preocupa com o software como produto
descartando deste conceito programas que so feitos unicamente para diverso do
programador e programas descartveis.
C4#en'e uma pessoa f#sica ou jur#dica que contrata a e%ecuo de um
projeto ou um ser representante autori!ado com poder de aceitao de propostas e
produtos. A pessoa que efetivamente usar um produto ser chamada de -1-2"#%
podendo ser o pr-prio c"iente um funcionrio de uma organi!ao c"iente ou mesmo
no ser re"acionado diretamente com o c"iente. 6or e%emp"o quando se produ!
software de prate"eira que ser vendido no mercado a$erto *ti" considerar como
c"iente o departamento de mar8eting da organi!ao produtora.
(omo todo produto industria" o software tem um cic"o de vida,
- e"e conce$ido a partir da percepo de uma necessidade5
- desenvo"vido transformando7se em um conjunto de itens
entregue a um c"iente5
- entra em operao sendo usado dentro de a"gum processo de
neg-cio e sujeito a atividades de manuteno quando necessrio5
- retirado de operao ao fina" de sua vida *ti".
C
I
C
L
O

D
E

6
I
D
A
9
a
$
e
"
a

/
.
/
6ercepo da necessidade
De1en5%45#+en'%
(oncepo
E"a$orao
C%n'"-./%
2esenho inicia"
L#3e"!./%
2esenho
deta"hado
C%$#&#*!./%
9estes de
unidade
9estes a"fa
9ransio
Operao
4etirada
:a 9a$e"a /./ a (odificao que representa a escrita fina" de um

programa em forma inte"ig#ve" para um computador apenas uma pequena parte do
cic"o de vida. 6ara a maioria das pessoas inc"usive muitos profissionais da
informtica esta parece ser a *nica tarefa de um programador ou seja um produtor
de software.
0.0.0 P"%7e'%1
:orma"mente o desenvo"vimento de software feito dentro de um
projeto. 9odo projeto tem uma data de in#cio uma data de fim uma equipe ;da qua"
fa! parte um responsve" a que chamaremos gerente de projeto0 e outros recursos.
<m projeto representa a e%ecuo de um processo.
=uando um processo $em definido e"e ter su$divis&es que
permitam ava"iar o progresso de um projeto e corrigir seus rumos quando ocorrerem
pro$"emas. Essas su$divis&es so chamadas de fases atividades ou itera&es5
posteriormente usaremos estas pa"avras com significados tcnicos espec#ficos.
As su$divis&es devem ser terminadas por +!"*%1 isto pontos que
representam estados significativos do projeto. >era"mente os marcos so
associados a resu"tados concretos, documentos mode"os ou por&es do produto
que podem fa!er parte do conjunto prometido aos c"ientes ou ter apenas uti"i!ao
interna ao projeto. O pr-prio produto um resu"tado associado ao marco de
conc"uso do projeto.
0.8 Re9-#1#'%1
0.8.1 C!"!*'e":1'#*!1
O va"or de um produto vem de suas caracter#sticas. 9ratando7se de
software costuma7se dividir as caracter#sticas em,
- caracter#sticas &-n*#%n!#1 que representam os comportamentos
que um programa ou sistema deve apresentar diante de certas
a&es de seus usurios5
- caracter#sticas n/% &-n*#%n!#1 que quantificam determinados
aspectos do comportamento.
6or e%emp"o em um termina" de cai%a automtico os tipos de
transa&es $ancrias suportadas so caracter#sticas funcionais. A faci"idade de uso
o tempo de resposta e o tempo mdio entre fa"has so caracter#sticas no
funcionais.
Os "e9-#1#'%1 so as caracter#sticas que definem os critrios de
aceitao de um produto. A engenharia tem por o$jetivo co"ocar nos produtos as
caracter#sticas que so requisitos. Outras caracter#sticas podem aparecer
acidenta"mente mas os produtos no devem ser desenhados para inc"u#7"as j que
norma"mente toda caracter#stica e%tra significa um custo adiciona" de desenho ou de
fa$ricao.
0.8.0 E1,e*#&#*!./% $%1 "e9-#1#'%1
Os requisitos podem ser dos seguintes tipos,
!
!
- Os requisitos e%p"#citos so aque"es descritos em um documento
que arro"a os requisitos de um produto ou seja um documento de
especificao de requisitos.
- Os requisitos normativos so aque"es que decorrem de "eis
regu"amentos padr&es e outros tipos de normas a que o tipo de
produto deve o$edecer.
- Os requisitos imp"#citos so e%pectativas dos c"ientes e usurios
que so co$radas por estes em$ora no documentadas.
4equisitos imp"#citos so indesejveis porque no sendo
documentados provave"mente no sero considerados no desenho do produto. O
resu"tado ser um produto que em$ora satisfa!endo os compromissos formais que
so os requisitos e%p"#citos e normativos no atender ?s necessidades do
consumidor.
)esmo requisitos documentados podem apresentar pro$"emas. <ma
especificao de requisitos pode conter requisitos incomp"etos inconsistentes ou
am$#guos norma"mente decorrentes da pr-pria "inguagem natura" usada para
e%pressa7"os. Outros decorrem de tcnicas deficientes de e"a$orao dos requisitos.
0.8.8 Engen!"#! $%1 "e9-#1#'%1
<m dos pro$"emas $sicos da engenharia de software o
"evantamento e documentao dos requisitos dos produtos de software. =uando
este "evantamento $em7feito os requisitos imp"#citos so minimi!ados. =uando a
documentao $em7feita os requisitos documentados tm maiores chances de
serem corretamente entendidos pe"os desenvo"vedores. A"gumas tcnicas de an"ise
dos requisitos ajudam a produ!ir especifica&es mais precisas e inte"ig#veis. O
conjunto das tcnicas de "evantamento documentao e an"ise forma a engenharia
dos requisitos que uma das discip"inas da Engenharia de 'oftware.
(a$e aos engenheiros de software convencerem c"ientes e usurios
da necessidade da e"a$orao de uma $oa especificao de requisitos. <ma $oa
especificao de requisitos custa tempo e dinheiro a ausncia de"a custa muito mais
tempo e dinheiro. A participao dos usurios na engenharia de requisitos
fundamenta" para que as suas necessidades sejam corretamente atendidas pe"o
produto.
0.8.; Ge1'/% $%1 "e9-#1#'%1
<m pro$"ema comum no desenvo"vimento de software a insta$i"idade
dos requisitos que ocorre quando c"ientes e usurios tra!em novos requisitos ou
a"tera&es de requisitos quando o desenvo"vimento j est em fase adiantada. A
insta$i"idade dos requisitos costuma ter um custo muito a"to gera"mente significa
perder tra$a"ho j feito desfa!er a"gumas coisas e remendar outras. :a Engenharia
de 'oftware a insta$i"idade dos requisitos to danosa quanto nas outras
engenharias. =uando se muda a p"anta de um edif#cio durante a construo
gera"mente preciso desfa!er parte do que j foi constru#do e o remendo raramente
satisfat-rio. A gesto dos requisitos a discip"ina da engenharia de software que
procura manter so$ contro"e o conjunto dos requisitos de um produto mesmo diante
de a"gumas a"tera&es inevitveis.
"
"
0.; P"!<%1 e *-1'%1
0.;.1 Re!4#1+% $e ,"!<%1 e *-1'%1
6or que tantos sistemas informati!ados so entregues com atraso e
custam mais do que o previsto? Estourar cronogramas e oramentos parte da
rotina da maioria dos profissionais de software. ("ientes e gerentes se desesperam
com os atrasos dos projetos de software e ?s ve!es sofrem enormes preju#!os com
e"es.
Estimar pra!os e custos fa! parte da rotina de qua"quer ramo da
engenharia. 6ara um produto ser vive" no $asta que atenda aos requisitos
desejados5 tem de ser produ!ido dentro de certos par@metros de pra!o e custo. 'e
isso no for poss#ve" o produto pode no ser vive" do ponto de vista de mercado
ou pode ser prefer#ve" adquirir outro produto ainda que sacrificando a"guns dos
requisitos.
O pro$"ema que e%istem a"guns desenvo"vedores inescrupu"osos.
E%istem muitos que mesmo sendo honestos no conhecem mtodos tcnicos de
estimativa de pra!os e custos do desenvo"vimento de software. E%istem ainda os
que mesmo sa$endo fa!er $oas
estimativas tra$a"ham em organi!a&es
onde no e%iste c"ima para que os
desenvo"vedores possam apresentar
ava"ia&es francas das perspectivas dos
projetos.
4equisitos pra!os e custos
formam os vrtices de um tri@ngu"o
cr#tico. Aumentos de requisitos "evam a
aumentos de pra!os ou de custos ou de
am$os. 4edu&es de requisitos podem
"evar a redu&es de pra!os ou de custos
;mas nem sempre0.
0.;.0 P4!ne7!+en'% $e ,"%7e'%1
<ma coisa e%igir dos engenheiros de sogtware estimativas de pra!os
e co$rar o cumprimento dos pra!os prometidos. ("ientes e gerentes podem e devem
fa!e7"o. Outra coisa pressiona7"os para que faam promessas que no podem ser
cumpridas. <ma frase comum dessa cu"tura , A:o me interessa como voc vai
fa!er desde que entregue no pra!oBC. :a rea"idade o c"iente ou gerente deve no
seu pr-prio interesse ter a"gum meio de checar se o cronograma e o oramento
propostos so rea"istas e se preciso recorrer aos servios de uma terceira parte
para fa!er esta verificao.
A cu"tura do pra!o po"#tico ruim para todos. 6ara os desenvo"vedores
e"a significa estresse e m qua"idade de vida. 6ara os gerentes perda de
credi$i"idade e preju#!os. E para os c"ientes produtos de m qua"idade e mais caros
do que deveriam. Ainda por cima entregues fora do pra!o.
6ara cumprir compromissos de pra!os e custos esses compromissos
tm de ser assumidos com $ase em requisitos $em "evantados ana"isados e
documentos. E os p"anos dos projetos tm de ser feitos com $oas tcnicas de
#
#
P$%&'S
()S*'S
$E+),S,*'S
estimativa e an"ise de tamanho esforos pra!os e riscos. Estas tcnicas
pertencem ? discip"ina de p"anejamento de projetos que fa! parte da Engenharia de
'oftware.
0.;.8 C%n'"%4e $e ,"%7e'%1
Ao "ongo de um projeto os gerentes tm de enfrentar pro$"emas e
tentar contro"ar variveis que afetem o cumprimento de seus compromissos.
A"gumas ve!es os pro$"emas podem ser reso"vidos por meio de contratao e
remanejamento de pessoa" ou de uma me"horia de ferramentas. Outras ve!es no
e%iste a"ternativa a no ser renegociar requisitos pra!os ou custos. O contro"e dos
projetos compreende, a0 o acompanhamento do progresso dos projetos
comparando7se o p"anejado com o rea"i!ado5 $0 a $usca de a"ternativas para
contornar pro$"emas surgidos na e%ecuo dos projetos5 c0 o rep"anejamento dos
projetos quando no poss#ve" manter os p"anos anteriores dentro de um grau
ra!ove" de variao5 d0 a renegociao dos compromissos assumidos envo"vendo
todas as partes interessadas.
0.= >-!4#$!$e
0.=.1 C%n&%"+#$!$e *%+ "e9-#1#'%1
Entenderemos como 9-!4#$!$e de um produto o seu grau de
*%n&%"+#$!$e *%+ %1 "e9-#1#'%1 ou seja o confronto entre a promessa e a
rea"i!ao de cada produto.
>era"mente a qua"idade de um produto decorre diretamente da
qua"idade do processo uti"i!ado na produo de"e no do Aprocesso oficia"C. )uitas
ve!es os processos oficiais no so seguidos na prtica por deficincia de
ferramentas por fa"ta de qua"ificao das pessoas ou porque press&es de pra!o
"evam os gerentes dos projetos a e"iminar etapas re"acionadas com contro"e da
qua"idade.
Em um produto de software de m qua"idade muitos requisitos no so
atendidos comp"etamente. As deficincias de conformidade com os requisitos se
manifestam de vrias maneiras. Em a"guns casos certas fun&es no so e%ecutas
corretamente so$ certas condi&es ou para certos va"ores de entrada. Em outros
casos o produto tem desempenho insuficiente ou dif#ci" de usar.
(ada requisito no atendido um $e&e#'%. :o mundo da informtica
criou7se a usana de chamar de A$ugsC os defeitos de software. Os defeitos inc"uem
situa&es de fa"ta de conformidade com requisitos e%p"#citos normativos e imp"#citos.
Os defeitos associados a requisitos imp"#citos so os mais dif#ceis de tratar. E"es
"evam a desentendimentos sem so"uo entre o fornecedor e o c"iente do produto.
A"m disso como esses requisitos por definio no so documentos $astante
provve" que e"es no tenham sido "evados em conta no desenho do produto o que
tornar a correo dos defeitos particu"armente tra$a"hosa.
0.=.0 G!"!n'#! $e 9-!4#$!$e
<m erro conceitua" comum imaginar que poss#ve" trocar pra!o e
ta"ve! custo por qua"idade. :a rea"idade poss#ve" em muitos casos redu!ir
pra!os e custos atravs da reduo dos requisitos de um produto. A qua"idade por
-
-
outro "ado conseqDncia dos processos das pessoas e da tecno"ogia. A re"ao
entre a qua"idade do produto e cada um desses fatores comp"e%a. 6or isso
muita mais dif#ci" contro"ar o grau de qua"idade do produto do que contro"ar os
requisitos.
Em todas as fases do desenvo"vimento de software as pessoas
introdu!em defeitos. E"es decorrem de "imita&es humanas, erros "-gicos erros de
interpretao desconhecimento de tcnicas fa"ta de ateno ou fa"ta de motivao.
Em todo $om processo e%istem atividades de garantia da qua"idade tais como
revis&es testes e auditorias. Essas atividades removem parte dos defeitos
introdu!idos. =uando atividades de contro"e da qua"idade so cortadas parte dos
defeitos dei%a de ser removida em um ponto do projeto para serem detectados
depois. =uando mais tarde um defeito corrigido mais cara a sua correo. O pior
caso acontece quando o defeito chega ao produto fina". :este caso e"e ser
removido da forma mais cara na +!n-'en./%. Em certos casos como acontece em
sistemas de misso cr#tica defeitos de software podem tra!er preju#!os irreparveis.
.rios mtodos de garantia da qua"idade "evam em conta uma
"imitao humana, somos mais efica!es para achar os defeitos dos outros do que os
nossos pr-prios defeitos. 6or isso os tipos mais eficientes de reviso so feitos por
revisores distintos dos autores.
0.=.8 Ge1'/% $e *%n&#g-"!.?e1
<m produto de software composto por muitos !"'e&!'%1, c-digos
e%ecutveis c-digos fontes mode"os re"at-rios e outros documentos. A"guns
desses artefatos so resu"tados oficiais do projeto5 a aprovao dos resu"tados
assina"a que um marco do projeto foi cumprido. Outros artefatos tm carter mais
informa"Epor e%emp"o documentos e mode"os temporrios de tra$a"ho dos
desenvo"vedores.
A maioria dos artefatos evo"ui ao "ongo de um projeto e at ao "ngo de
toda a vida de um produto. )esmo depois de terminado um projeto importante que
os resu"tados sejam guardados e contro"ados. 6ode ser necessrio atua"i!a7"os em
caso de manuteno.
)esmo um pequeno projeto pode gerar mais de uma de!ena de
resu"tados diferentes cada um com mais de uma de!ena de vers&es. Organi!ar e
contro"ar a pro"iferao dos artefatos o o$jetivo da discip"ina de ge1'/% $e
*%n&#g-"!.?e1.
0.=.; Ge1'/% $e *%n'"!'%1
9erceiri!ar o desenvo"vimento de software uma $oa so"uo em
muitos casos. )as no panacia. O esforo de uma organi!ao para me"horar a
qua"idade de seus sistemas informati!ados pode ser perdido por causa de fa"has dos
contratados. 6ara que isso no acontea a organi!ao contratante deve estar
capacitada em ge1'/% $e *%n'"!'%1. 6ara isso e"e tem de ser capa! no m#nimo
de, a0 especificar correta e comp"etamente o produto a ser desenvo"vido5 $0 fa!er
uma $oa se"eo entre os candidatos a su$contratado ava"iando o grau de rea"ismo
das propostas destes5 c0 acompanhar o desempenho do su$contratado sem interferir
no tra$a"ho deste mas detectando precocemente sintomas de pro$"emas5 d0
p"anejar e e%ecutar os procedimentos de aceitao do produto.
.
.
0.=.= De1en%
Os defeitos mais grosseiros de um produto de software so os defeitos
de requisitos. E"es no entanto so re"ativamente raros desde que a engenharia de
requisitos tenha sido "evada a srio tanto por desenvo"vedores quanto por usurios.
2efeitos de imp"ementao por outro "ado so mais comuns. :o entanto
programados e%perientes em uma "inguagem de programao no erram com
freqDncia principa"mente quando fa!em revis&es cuidadosas de seu c-digo.
Entre os requisitos e o c-digo fina" e%iste sempre um $e1en%. E"e
pode ser e%p"#cito documentado e feito de acordo com determinadas tcnicas ou
pode e%istir apenas na ca$ea do programados de maneira informa" e
semiconsciente.
2efeitos de desenho tm gera"mente conseqDncias graves em todos
os ramos da engenharia. Em constru&es por e%emp"o erros de desenho podem
"evar a va!amentos perigo de incndios rachaduras e at desa$amentos. As
conseqDncias nos produtos de software so igua"mente srias. A"guns resu"tados
t#picos de defeitos de desenho so, a0 dificu"dade de uso5 $0 "entido5 c0 pro$"emas
imprevis#veis e irreprodut#veis5 d0 perda de dados5 e0 dificu"dade de manuteno5 f0
dificu"dade de adaptao e de e%panso.
0.=.@ M%$e4%1 $e +!'-"#$!$e
A maturidade de uma organi!ao em Engenharia de 'oftware mede o
grau de competncia tcnica e gerencia" que essa organi!ao possui para
produ!ir software de $oa qua"idade dentro de pra!os e custos ra!oveis e
previs#veis.
A e%istncia de processos definidos necessria para a maturidade
das organi!a&es produtoras de software. Os processo definidos permitem que a
organi!ao tenha um modus operandi padroni!ado e reprodut#ve". Fsso faci"ita a
capacitao das pessoas e torna o funcionamento da organi!ao menos
dependente de determinados indiv#duos. Entretanto no suficiente que os
processo sejam definidos. 6rocessos rigorosamente definidos mas no a"inhados
com os o$jetivos da organi!ao so entraves $urocrticos e no fatores de
produo.
6ara tornar uma organi!ao mais madura e capacitada rea"mente
preciso me"horar a qua"idade dos seus processos. 6rocessos no me"horam
simp"esmente por estarem de acordo com um padro e%terno. O critrio de
verdadeiro %ito dos processos a medida de quanto e"es contri$uem para que os
produtos sejam entregues aos c"ientes e usurios com me"hor qua"idade por menor
custo e em pra!o mais curto.
2iversas organi!a&es do mundo propuseram paradigmas para a
me"horia dos processos dos setores produtivos5 em particu"ar a"gumas
desenvo"veram paradigmas para a me"horia dos processos de software. Estes
paradigmas podem assumir diversas formas. Fnteressam aqui especia"mente os
paradigmas do tipo +%$e4%1 $e *!,!*#'!./%. <m mode"o de capacitao serve
para ava"iar a maturidade dos processos de uma organi!ao. E"e serve de
referncia para ava"iar7se a maturidade destes processos.
/
/
<m mode"o de capacitao particu"armente importante para a rea de
software o ()) ;(apa$i"itG maturitG )ode"0 do 'oftware Engineering Fnstitute. O
()) patrocinado pe"o 2epartamento de 2efesa americano que o uti"i!a para
ava"iao da capacidade de seus fornecedores de software. Esse mode"o teve
grande aceitao da ind*stria americana de software e considerve" inf"uncia no
resto do mundo.
O ()) foca"i!a os processos que considera o fator de produo com
maior potencia" de me"horia a pra!o mais curto. Outros fatores como tecno"ogia e
pessoas s- so tratados pe"o ()) na medida em que interagem com os processos.
6ara enfati!ar que o escopo do ()) se "imita aos processos de software o 'EF
passou a denomina7"o de 'H7()) para distingui7"o de outros mode"os de
capacitao ap"icveis a reas como desenvo"vimento humano engenharia de
sistemas definio de produtos e aquisio de software. :este te%to fica entendido
que ()) se refere sempre ao 'H7()). A ta$e"a /.3 resume os n#veis do ())
destacando as caracter#sticas mais marcantes de cada n#ve".
Tabela 1.3 N:5e#1 $% CMM
NA+e"% $%
n:5e4
N%+e $%
n:5e4
C!"!*'e":1'#*! $!
%"g!n#<!./%
C!"!*'e":1'#*! $%1
,"%*e11%1
N:5e4 1 Fnicia" :o segue rotinas 6rocessos ca-ticos
N:5e4 0 4epetitivo 'egue rotinas 6rocessos discip"inados
N:5e4 8 2efinido Esco"he rotinas 6rocessos padroni!ados
N:5e4 ; >erido (ria e aperfeioa rotinas 6rocessos previs#veis
N:5e4 = Otimi!ante Otimi!a rotinas
6rocessos em me"horia
cont#nua
10
10
CAPTULO 0 PROCESSOS
1 6ISBO GERAL

1.1 P"%*e11%1 e+ ge"!4
<m processo um conjunto de passos parcia"mente ordenados
constitu#dos por atividades mtodos prticas e transforma&es usado para atingir
uma meta. Esta meta gera"mente est associada a um ou mais resu"tados concretos
finais que so os produtos da e%ecuo do processo.
<m processo uma receita que seguida por um projeto5 o projeto
concreti!a uma a$strao que o processo. :o se deve confundir um processo
;digamos uma receita de risoto de camaro0 com o respectivo produto ;risoto de
camaro0 ou com a e%ecuo do processo atravs de um projeto ;a confeco de
um risoto de camaro por determinado co!inheiro em determinado dia0.
<m processo definido quando tem documentao que deta"ha,
- o que feito ;produto0
- quando ;passos0
- por quem ;agentes0
- as coisas que usa ;insumos0
- as coisas que produ! ;resu"tados0.
1.0 P"%*e11%1 $e 1%&'(!"e
Em Engenharia de 'oftware processos podem ser definidos para
atividades como desenvo"vimento manuteno aquisio e contratao de
software. 6ode7se tam$m definir su$processos para cada um destes por e%emp"o
um processo de desenvo"vimento a$range su$processos de determinao dos
requisitos an"ise desenho imp"ementao e testes. Em um processo de
desenvo"vimento de software o ponto de partida para a arquitetura de um processo
a esco"ha de um mode"o de cic"o de vida.
O cic"o de vida mais ca-tico aque"e que pode ser chamado de
AC%$#&#*!C"e+en$!C. 6artindo apenas de uma especificao ;ou nem isso0 os
desenvo"vedores comeam imediatamente a codificar remendando ? medida que os
erros vo sendo desco$ertos. :enhum processo definido seguido. Fnfe"i!mente
provave"mente o cic"o de vida mais usado. 6ara a"guns desenvo"vedores esse
mode"o atraente porque no e%ige nenhuma sofisticao tcnica ou gerencia". 6or
outro "ado um mode"o de a"to risco imposs#ve" de gerir e que no permite assumir
compromissos confiveis.
:o mode"o de cic"o de vida de C!1*!'! os principais su$processos
so e%ecutados em estrita seqDncia o que permite demarca7"as com ,%n'%1 $e
*%n'"%4e $em definidos. Estes pontos de contro"e faci"itam muito a gesto dos
projetos o que fa! com que esse processo seja em princ#pio confive" e uti"i!ve"
em projetos de qua"quer esca"a. 6or outro "ado se interpretado "itera"mente um
processo r#gido e $urocrtico em que as atividades de requisitos an"ise e desenho
tm de ser muito $em dominadas pois no so permitidos erros. O )ode"o de
11
11
cascata puro de $ai%a visi$i"idade para o c"iente que s- rece$e o resu"tado fina" do
projeto.
:a prtica sempre necessrio permitir que em fases posteriores
haja reviso e a"terao de resu"tados das fases anteriores. 6or e%emp"o os
mode"os e documentos de especificao e desenho podem ser a"terados durante a
imp"ementao na medida em que pro$"emas vo sendo desco$ertos. <ma variante
que permite superposio entre fases e a rea"imentao de corre&es o mode"o
DS!1#+#C. A superposio das fases torna dif#ci" gerenciar projetos $aseados nesse
mode"o de cic"o de vida.
<m mode"o de cic"o de vida radica"mente diferente o mode"o em
E1,#"!4. O produto desenvo"vido em uma srie de itera&es. (ada nova iterao
corresponde a uma vo"ta na espira". Fsso permite construir produtos em pra!os
curtos com novas caracter#sticas e recursos que so agregados na medida em que
a e%perincia desco$re sua necessidade. As atividades de manuteno so usadas
para identificar pro$"emas5 seus registros fornecem dados para definir os requisitos
das pr-%imas "i$era&es. O principa" pro$"ema do cic"o de vida em espira" que e"e
requer gesto muito sofisticada para ser previs#ve" e confive".
<ma variante do mode"o em espira" o mode"o de P"%'%'#,!ge+
e5%4-'#5!. :este mode"o a espira" usada no para desenvo"ver o produto
comp"eto mas para construir uma srie de vers&es provis-rias que so chamadas
de prot-tipos. Os prot-tipos co$rem cada ve! mais requisitos at que se atinja o
produto desejado. A prototipagem evo"utiva permite que os requisitos sejam
definidos progressivamente e apresenta a"ta f"e%i$i"idade e visi$i"idade para os
c"ientes. Entretanto tam$m requer gesto sofisticada e o desenho deve ser de
e%ce"ente qua"idade para que a estrutura do produto no se degenere ao "ongo dos
prot-tipos.
O mode"o de En'"eg! ,%" e1'2g#%1 difere do mode"o de cascata pe"a
entrega ao c"iente de "i$era&es parciais do produto. Fsso aumenta a visi$i"idade do
projeto o que gera"mente um fator muito importante no re"acionamento com o
c"iente. Apresenta entretanto os demais defeitos do mode"o em cascata.
<ma com$inao dos mode"os de (ascata e 6rototipagem evo"utiva
forma o mode"o de En'"eg! E5%4-'#5!. Este mode"o permite que em pontos $em
definidos os usurios possam ava"iar partes do produto e fornecer rea"imentao
quanto ?s decis&es tomadas. +aci"ita tam$m o acompanhamento do progresso de
cada projeto tanto por parte de seus gerentes como dos c"ientes. A principa"
dificu"dade continua ser a rea"i!ao do 2esenho Fnicia", e"e deve produ!ir uma
arquitetura de produto ro$usta que se mantenha #ntegra ao "ongo dos cic"os de
"i$era&es parciais.
Em mode"os $#"#g#$%1 ,%" ,"!<% ;time7$o%ed0 o produto aqui"o que
se consegue fa!er dentro de determinado pra!o. Esses mode"os podem ser
ra!oveis quando se consegue definir um conjunto de requisitos indispensveis para
os quais se sa$e que os pra!os esta$e"ecidos so suficientes e a fo"gas so usadas
apenas para imp"ementar requisitos opcionais. :a prtica os pra!os costumam ser
definidos de forma po"#tica e o AprodutoC que se entrega no fina" do pra!o apenas
um resu"tado parcia". Este ser comp"etado aos trancos e $arrancos em
desenvo"vimento posterior disfarado de AmanutenoC.
12
12
O cic"o de vida pode ser tam$m $#"#g#$% ,%" &e""!+en'! ;que pode
ser chamada de ferramenta de (A'E ou p"ataforma de desenvo"vimento pe"os
respectivos fa$ricantes0. A"gumas ferramentas imp&em processos r#gidos que
podem ser adequados para tipos $em espec#ficos de produtos. A qua"idade destes
processos depende fundamenta"mente da qua"idade da ferramenta e de que o uso
do processo seja restrito ao seu dom#nio de ap"icao.
<ma so"uo tentadora pode ser comprar em ve! de desenvo"ver.
=uando se encontra um produto que atende aos requisitos desejados uma $oa
so"uo. :esse caso no h processo de desenvo"vimento mas e%istiro processos
de aquisio de imp"antao e possive"mente de adaptao e integrao com
outros sistemas. 2ependendo dos casos esse conjunto de processos pode ser mais
sofisticado e caro do que um processo de desenvo"vimento.
0 EEEMPLOS DE PROCESSOS
0.1 O P"%*e11% ,e11%!4 $e S%&'(!"e
(omo foi mencionado anteriormente nos primeiros anos de e%istncia
do paradigma ()) as organi!a&es ava"iadas nos n#veis superiores de maturidade
eram muito poucas. <ma caracter#stica destes n#veis o uso de processos definidos
de forma precisa e quantitativa que possam ser continuamente me"horados.
6artindo do princ#pio de que para atingir os n#veis superiores de
maturidade era necessrio me"horar a prtica dos processos em n#ve" dos
desenvo"vedores individuais Hatts IumphreG propJs uma srie de processos
pessoais que pudessem ser aprendidos em uma discip"ina de engenharia de
software. Esse conjunto chamado de 6rocesso 6essoa" de 'oftware ;6ersona"
'oftware process0 ou 6'6.
TABELA 2.2 - OS ESTGIOS DO PSP
6rocessos pessoais $sicos
PSPF
4egistro de tempos
4egistro de defeitos
6adroni!ao dos tipos de defeitos
PSPF.1
6adroni!ao da codificao
)edio do tamanho
6roposio de me"horias de processo
6rocessos pessoais com p"anejamento
PSP1
Estimativas de tamanho
4e"at-rios de testes
PSP1.1
6"anejamento de tarefas
6"anejamento de cronogramas
6rocessos pessoais com gesto da qua"idade
PSP0
4evis&es de c-digo
4evis&es de desenho
PSP0.1 )ode"os de desenho
6rocessos pessoais c#c"icos PSP8 2esenvo"vimento c#c"ico

Esses processos so aprendidos atravs de uma seqDncia de
pequenos projetos contida nesse "ivro. Os projetos devem ser rea"i!ados seguindo
rigorosamente os processos que inc"uem um conjunto de formu"rios scripts e
re"at-rios predefinidos. Os projetos so individuais com durao t#pica de cerca de
/K horas.
1
1
A ta$e"a 1.3 apresenta deta"hes do 6'63 verso fina" do processo
que inc"ui os e"ementos introdu!idos em todos os processos anteriores. O 6'63 tem
um cic"o de vida de entrega em estgios. :o e%iste um tratamento separado dos
requisitos5 estes so muito simp"es em todos os projetos e as respectivas atividades
so consideradas parte do p"anejamento. O p"anejamento inc"ui a estimativa de
tamanhos ;medidos em "inhas de c-digo com $ase em um mode"o conceitua"
orientado a o$jetos0 de esforos ;medidos em tempo de desenvo"vimento0 de
cronograma ;tempo f#sico0 e de defeitos.
Tabela 2.3 De'!4e1 $% PSP8
F!1e A'#5#$!$e1 Re1-4'!$%1
6"anejamento Especificao dos requisitos
Estimativa de tamanho
Estratgia
Estimativa de recursos
Estimativa de pra!os
Estimativa de defeitos
2ocumentos dos requisitos
)ode"o conceitua"
6"anos de recursos pra!os e
qua"idade
4egistro de tempos
2esenho de a"to
n#ve"
Especifica&es e%ternas
2esenho dos m-du"os
6rototipagem
Estratgia de desenvo"vimento
2ocumentao da estratgia de
desenvo"vimento
4egistro de acompanhamento de
pro$"ema
Especifica&es funcionais
Especifica&es de estados
4oteiros operacionais
Especifica&es de reuti"i!ao
Estratgia de testes
4egistro de tempos
4eviso do
desenho de a"to
n#ve"
.erificao da co$ertura do desenho
.erificao da mquina de estados
.erificao "-gica
.erificao da consistncia do
desenho
.erificao da reuti"i!ao
.erificao da estratgia de
desenvo"vimento
(onserto de defeitos
2esenho de a"to n#ve" revisto
revista
Estratgia de teste revista
4egistro de defeitos de desenho
de a"to n#ve"
4egistro de pro$"emas de
desenho de a"to n#ve"
4egistro de tempos
2esenvo"vimento 2esenho do m-du"o
4eviso do desenho
(odificao
4eviso do c-digo
(ompi"ao
9este
4eava"iao e recic"agem
2esenho deta"hado dos m-du"os
(-digo dos m-du"os
4egistro de defeitos dos m-du"os
4egistro de prog"emas dos
m-du"os
4e"at-rios dos testes
4egistro de tempos
6ost7mortem (ontagem de defeitos injetados e
removidos
(ontagem de tamanhos e tempos
4esumo do projeto
1!
1!
O desenho feito de acordo com padr&es rigorosos que usam
conceitos de orientao a o$jetos s#ntese "-gica e mquinas seqDenciais e
su$metido a uma fase rigorosa de verificao. (om $ase no desenho a fase de
desenvo"vimento dividida em cic"os, cada cic"o inc"ui desenho deta"hado
codificao reviso do c-digo compi"ao e testes de unidade dos respectivos
m-du"os. Ao fina" de cada cic"o o p"anejamento reava"iado. O 6'6 sempre termina
com uma fase de post7mortem na qua" feito um $a"ano fina" do projeto. As "i&es
aprendidas so documentadas e ana"isadas para me"horia do processo no projeto
seguinte.
0.0 O P"%*e11% $e S%&'(!"e ,!"! T#+e1
(omo seqDncia natura" do 6'6 IumphreG introdu!iu o 6rocesso de
'oftware para 9imes ;9eam 'oftware 6rocess0 ou 9'6. O 9'6 usa um mode"o em
espira"5 os passos mostrados na ta$e"a 1.L apresentam as partes principais da
verso pu$"icada desse processo ;9'6e0 que orientada para uti"i!ao
educaciona" e correspondem a um dos cic"os. Ao "ongo de /M semanas so
e%ecutados tipicamente trs cic"os de desenvo"vimento de um produto.
Tabela 2.4 - F!1e1 $% TSPe ,!"'e 1
F!1e A'#5#$!$e1
L!n.!+en'% 2escrio do curso,
- viso gera"
- informao para os a"unos
- o$jetivos do produto
+ormao dos times, integrantes metas e reuni&es
6rimeira reunio do time, requisitos de dados
Ativao dos projetos
E1'"!'Gg#! .iso gera" da estratgia de desenvo"vimento
(ritrios da estratgia de desenvo"vimento
'e"eo da estratgia de desenvo"vimento
2ocumentao da estratgia de desenvo"vimento
Estimativas de tamanho
2efinio do processo de contro"e de mudanas
P4!ne7!+en'% .iso gera" do p"ano de desenvo"vimento
6roduo do p"anos de tarefas
6roduo do cronograma
6roduo dos p"anos pessoais dos engenheiros
Na"anceamento de carga dos engenheiros
6roduo do p"ano da qua"idade
Re9-#1#'%1 4eviso do processo de requisitos
4eviso das demandas dos usurios
Esc"arecimento das demandas dos usurios
2istri$uio das tarefas de requisitos
2ocumentao dos requisitos
4eviso dos requisitos
(o"ocao dos requisitos na "inha de $ase
4eviso dos requisitos pe"os usurios
1"
1"
Os participantes do time de desenvo"vedores so organi!ados de ta"
forma que cada desenvo"vedor desempenhe um ou dois papis gerenciais $em
definidos a"m de dividir a carga de desenvo"vimento. Os papis suportados pe"o
processo so os de gerente de desenvo"vimento de p"anejamento de qua"idade de
processo e de suporte a"m do "#der do time.
0.8 O ,"%*e11% O"#en'!$% ! O37e'%1 ,!"! S%&'(!"e EH'en1:5e4
O 6rocesso orientado a O$jetos para 'oftware E%tens#ve" ;64O'E0 foi
desenvo"vido dentro do 2epartamento de (incia da (omputao da <niversidade
+edera" de )inas >erais. Origina"mente esse processo foi desenvo"vido para uso
em projetos de desenvo"vimento de sistemas de apoio ? Engenharia de
9e"ecomunica&es.
O 64O'E foi conce$ido com um processo padro que visava a co$rir
todo o cic"o de vida dos produtos de software especia"mente de ap"icativos
e%tens#veis atravs de sucessivas vers&es produ!idas durante um cic"o de vida de
produto com durao de vrios anos. Esses produtos norma"mente seriam
ap"icativos grficos interativos $aseados na tecno"ogia orientada a o$jetos.
Tabela 2.5 - PROSE
M!*"%!'#5#$!$e F!1e S-3&!1e
A'#5!./%
E1,e*#&#*!./% Engenharia dos
4equisitos
Oevantamento dos requisitos
2eta"hamento dos requisitos
6"anejamento 6"anejamento do desenvo"vimento
6"anejamento da qua"idade
De1en5%45#+en'% 2esenho 2esenho dos testes de aceitao
2esenho arquitetPnico
2esenho das interfaces de usurio
6"anejamento das "i$era&es
e%ecutveis
Fmp"ementao (onstruo da "i$erao e%ecutve"
/
(onstruo da "i$erao e%ecutve"
1
(onstruo da "i$erao
e%ecutve" ...
6reparao da imp"antao
9estes a"fa
I+,4!n'!./% 9estes $eta
Operao pi"oto
A ta$e"a 1.M descreve a estrutura $sica do 64O'E. O mode"o de ci"co
de vida de cada projeto o de entrega evo"utiva. O cic"o de vida de um produto
constitu#do por vers&es sucessivas que so produ!idas em diferentes projetos5
portanto o mode"o de cic"o de vida de produto em espira". )uitos dos e"ementos
do 64O'E serviram de $ase ao 64AQF' que ser descrito deta"hadamente adiante.
1#
1#
0.; O P"%*e11% Un#&#*!$%
Nooch Raco$son e 4um$augh propuseram a <)O como uma notao
de mode"agem orientada em o$jetos independente de processos de
desenvo"vimento. A"m disso propuseram o 6rocesso <nificado ;<nified 6rocess0
que uti"i!a a <)O como notao de uma srie de mode"os que comp&em os
principais resu"tados das atividades do processo. <m produto comercia" $aseado no
6rocesso <nificado o 4ationa" <nified 6rocess5 e"e contm uma $ase de
conhecimento que deta"ha e estende o materia" apresentado pe"os autores.
'egundo seus autores o 6rocesso unificado apresenta as seguintes
caracter#sticas centrais,
- dirigido por casos de uso5
- centrado na arquitetura5
- iterativo e incrementa"
O cic"o de vida de um produto tem um mode"o em espira" em que cada
projeto constitui um cic"o que entrega uma "i$erao do produto. O 6rocesso
<nificado no trata do que acontece entre cic"os. (ada cic"o dividido nas fases
mostradas na ta$e"a 1.S.
Tabela 2.6 FASES DO PROCESSO UNIFICADO
F!1e De1*"#./%
C%n*e,./% +ase na qua" se justifica a e%ecuo de um projeto de
desenvo"vimento de software do ponto de vista do neg-cio do
c"iente
E4!3%"!./% +ase na qua" o produto deta"hado o suficiente para permitir um
p"anejamento acurado da fase de construo
C%n1'"-./% +ase na qua" produ!ida um verso comp"etamente operaciona" do
produto
T"!n1#./% +ase na qua" o produto co"ocado ? disposio de uma
comunidade de usurios
<ma caracter#stica importante do 6rocesso unificado que as
atividades tcnicas so divididas em su$processos chamados de &4-H%1 $e '"!3!4%
;wor8f"ows0 mostrados na 9a$e"a 1.T. (ada f"u%o de tra$a"ho ;que chamaremos
simp"esmente de f"u%o0 tem um tema tcnico espec#fico enquanto as fases
constituem divis&es gerenciais caracteri!adas por atingirem metas $em definidas.
Tabela 2.7 U FLUEOS DO PROCESSO UNIFICADO
F4-H% De1*"#./%
Re9-#1#'%1 +"u%o que visa a o$ter um conjunto de requisitos de um produto
acordado entre c"iente e fornecedor
An24#1e +"u%o cujo o$jetivo deta"har estruturar e va"idar os requisitos de
forma que estes possam ser usados como $ase para o p"anejamento
deta"hado
De1en% +"u%o cujo o$jetivo formu"ar um mode"o estrutura" do produto que
sirva de $ase para a imp"ementao
Te1'e1 +"u%o cujo o$jetivo verificar os resu"tados da imp"ementao
1-
1-
8 PRAEIS
8.1 6#1/% Ge"!4
8.1.1 In'"%$-./%
O 64AQF' ;6rocesso para Ap"icativos eQtens#veis Fnterativo'0 um
processo desenhando para suportar projetos de seis meses a uma ano de durao
rea"i!ados individua"mente ou por pequenas equipes didaticamente em discip"inas
de engenharia de 'oftware. O 6ra%is a$range materia" re"ativo tanto a mtodos
gerenciais como tcnicos. E"e uti"i!a a e%perincia de desenvo"vimento do 64O'E
assim como e"ementos se"ecionados do 6'6 do 9'6 e do 6rocesso <nificado. O
6ra%is no su$stitui nem concorre com nenhum desses processos pois tem o$jetivos
diferentes podendo ser usado como $ase de treinamento preparat-rio para cada um
de"es.
A <)O a notao de mode"agem uti"i!ada no 6ra%is em todos os
passos em que for ap"icve". As prticas gerenciais so inspiradas nas prticas
chaves dos n#veis 1 e 3 do 'H7()) e padr&es correspondentes do FEEE ;FEEEVL0.
O materia" inc"ui mode"os de documentos que faci"itam a preparao dos
documentos requeridos e roteiros de reviso que faci"itam a verificao destes.
8.1.0 N%+en*4!'-"!
A nomenc"atura apresentada na 9a$e"a 1.W uti"i!ada para descrio
das unidades de tra$a"ho que comp&em o 6ra%is. :o esti"o do 6rocesso unificado o
6ra%is a$range tanto &!1e1 ;su$processos gerenciais0 quanto &4-H%1 ;su$processos
tcnicos0. <ma fase composta por uma ou mais #'e"!.?e1. <m f"u%o dividido em
uma ou mais e'!,!1. Ftera&es e etapas so e%emp"os de ,!11%1.
Tabela 2.8 E4e+en'%1 *%n1'#'-#n'e1 $e -+ ,"%*e11%
E4e+en'% De1*"#./%
P!11%
2iviso forma" de um processo com pr7requisitos entradas critrios
de aprovao e resu"tados definidos
F!1e
2iviso maior de um processo para fins gerenciais que corresponde
aos pontos principais de aceitao por parte do c"iente
I'e"!./%
6assos constituinte de uma fase no qua" se atinge um conjunto $em
definido de metas parciais de um projeto
F4-H%
'u$processo caracteri!ado por um tema tcnico
E'!,!
6asso constituinte de um f"u%o
A'#5#$!$e
9ermo genrico para unidades de tra$a"ho e%ecutadas em um passo
<m passo definido atravs de um script apresentado em forma de
ta$e"a. A 9a$e"a 1.V apresenta os e"ementos que sero uti"i!ados na apresentao
dos scripts. (ada passo est re"acionado com artefatos que consome ;insumos0 e
produ! ;resu"tados05 est sujeito a condi&es de entre ;pr7requisitos0 e de sa#da
;critrios de aprovao05 e e%ecuta uma srie de atividades sujeitas a normas
1.
1.
pertinentes. <ma atividade pode ser e%ecutava por vrios passos pode ser divis#ve"
ou no em outras atividades e est em um *nico f"u%o.
9a$e"a 1.V U Elementos do script de um passo do Praxis
E4e+en'% De&#n#./%
De1*"#./% +rase que resume a nature!a do passo
P"GC"e9-#1#'%1
(ondi&es que devem ser satisfeitas para
o in#cio de um passo compreendendo
tanto eventos e%ternos quanto passos
anteriores que devam ter sido
comp"etados e aprovados
In1-+%1
Artefatos cuja disponi$i"idade prvia
necessria para a e%ecuo de uma
atividade
A'#5#$!$e1 Atividades e%ecutadas durante um passo
Re1-4'!$%1
Artefatos produ!idos durante a e%ecuo
de um passo
C"#'G"#%1 $e !,"%5!./%
(ondi&es para que um passo seja
considerado comp"eto e aprovado
N%"+!1 ,e"'#nen'e1 :ormas ap"icveis a este passo
8.1.8 A"9-#'e'-"!
8.1.8.1 F!1e1
Os e"ementos maiores da arquitetura do 6ra%is so inspirados nos
e"ementos correspondentes do 6rocesso <nificado ;ta$e"a 1./K e 1.//0 tendo7se em
vista compati$i"i!ar a nomenc"atura com um processo que ter provave"mente
grande aceitao na ind*stria de software. As defini&es das fases e f"u%os so mais
espec#ficas em re"ao ?s op&es de desenho de processo adotadas no 6ra%is.
Tabela 2.10 F!1e1 n% P"!H#1
C%n*e,./% +ase na qua" necessidades dos usurios e conceitos da ap"icao
so ana"isados o suficiente para justificar a especificao de um
produto de software resu"tando em uma proposta de especificao
E4!3%"!./% +ase na qua" a especificao do produto deta"hada o suficiente
para mode"ar conceitua"mente o dom#nio do pro$"ema va"idar os
requisitos em termos desse mode"o conceitua" e permitir um
E4!3%"!./% +ase na qua" a especificao do produto deta"hada o suficiente
para mode"ar conceitua"mente o dom#nio do pro$"ema va"idar os
requisitos em termos desse mode"o conceitua" e permitir um
C%n1'"-./% +ase na qua" desenvo"vida ;desenha imp"ementada e testada0
uma "i$erao comp"etamente operaciona" do produto que atende
aos requisitos especificados.
T"!n1#./% +ase na qua" o produto co"ocado ? disposio de uma comunidade
de usurios para testes finais treinamento e uso inicia"
1/
1/
Tabela 2.11 F4-H%1 $% P"!H#1
Re9-#1#'%1
+"u%o que visa a o$ter um conjunto de requisitos de um produto
acordado entre c"iente e fornecedor
An24#1e
+"u%o que visa a deta"har estruturar e va"idar os requisitos em
termos de um mode"o conceitua" do pro$"ema de forma que estes
possam ser usados como $ase para o p"anejamento e
acompanhamento deta"hados da construo do produto
De1en%
+"u%o que visa a formu"ar um mode"o estrutura" do produto que
sirva de $ase para a imp"ementao definindo os componentes a
desenvo"ver e a reuti"i!ar assim como as interfaces entre si e com
o conte%to do produto
I+,4e+en'!./%
+"u%o que visa a deta"har e imp"ementar o desenho atravs de
componentes de c-digo e de documentao associada
Te1'e1
+"u%o que visa verificar os resu"tados da imp"ementao atravs do
p"anejamento desenho e rea"i!ao de $aterias de testes
8.1.8.0 I'e"!.?e1
A diviso das fases do 6ra%is o$edece ao mode"o de cic"o de vida de
entrega evo"utiva. Os nomes das itera&es foram esco"hidos de forma a i"ustrar o
tema principa" de cada. :o devem ser confundidos com os nomes seme"hantes de
f"u%os em$ora as coincidncias de nome ressa"tem os f"u%os mais importantes de
cada iterao.
A concepo contm uma *nica iterao chamada de AAtivaoC. A
e"a$orao consta das itera&es de AOevantamento dos 4equisitosC em que o foco
a captura dos requisitos junto aos usurios do produto e de AAn"ise dos
4equisitosC que foca"i!a o deta"hamento e a va"idao dos requisitos atravs de
tcnicas de an"ise.
A construo comea por uma iterao de A2esenho Fnicia"C em que
rea"i!ado o desenho do produto em n#ve" mais a"to de a$strao de forma a permitir
a diviso das fun&es e componentes do produto ao "ongo das itera&es seguintes.
Em seguida aparecem uma ou mais AOi$era&esC sendo a integrao fina" do
produto testada na iterao dos A9estes A"taC. :ote7se que todas as "i$era&es com
e%ceo da *"tima so "i$era&es parciais por no contemp"arem todos os
requisitos especificados.
A transio comea pe"os A9estes NetaC iterao na qua" os testes de
aceitao so repetidos no am$iente dos usurios. :a iterao de AOperao 6i"otoC
o produto usado de forma vigiada de preferncia em insta"a&es que contemp"em
o carter ainda e%perimenta" da operao. Em produtos comerciais de prate"eira a
transio gera"mente termina nos testes $eta enquanto em sistemas de misso
cr#tica a operao pi"oto pode "evar um "ongo tempo estendendo7se o uso do
produto gradua"mente atravs das insta"a&es do c"iente.
9erminado o cic"o de um projeto comea a operao do produto que
durar enquanto o produto no for su$stitu#do por nova verso ou no for
desativado.
20
20
Tabela 2.12 De'!4!+en'% $!1 &!1e1 $% P"!H#1
(oncepo Ativao Oevantamento e an"ise das necessidades dos usurios
e conceitos da ap"icao em n#ve" de deta"he suficiente
para justificar a especificao de um produto de software
E"a$orao Oevantamento
dos 4equisitos
Oevantamento deta"hados das fun&es interfaces e
requisitos no funcionais desejados para o produto
An"ise dos
4equisitos
)ode"agem conceitua" dos e"ementos re"evantes do
dom#nio do pro$"ema e uso desse mode"o para
va"idao dos requisitos e p"anejamento deta"hado da
fase de (onstruo
(onstruo 2esenho
Fnicia"
2efinio interna e e%terna dos componentes de um
produto de software em n#ve" suficiente para decidir as
principais quest&es de arquitetura e tecno"ogia e para
permitir o p"anejamento deta"hado das atividades de
imp"ementao
Oi$erao / Fmp"ementao de um su$conjunto de fun&es do
produto que seEr ava"iado pe"os usurios
Oi$erao... Fdem
Oi$erao
+ina"
Fdem
9estes A"fa 4ea"i!ao dos testes de aceitao no am$iente dos
desenvo"vedores juntamente com e"a$orao da
documentao de usurio e poss#veis p"anos de
9ransio
9ransio 9estes Neta 4ea"i!ao dos testes de aceitao no am$iente dos
usurios
Operao
6i"oto
Operao e%perimenta" do produto em insta"ao pi"oto
do c"iente com a reso"uo de eventuais pro$"emas
atravs de processo de manuteno
8.1.8.8 E4e+en'%1 $!1 #'e"!.?e1
(ada uma das itera&es deta"hada na pr-%ima su$seo. 6ara cada
iterao apresentado um script com os seguintes e"ementos,
- descrio sucinta da iterao5
- pr7requisitos internos e e%ternos ao processo5
- insumos da iterao inc"usive antigos ;consumidos tam$m por
itera&es anteriores0 e novos ;consumidos pe"a primeira ve! nesta
iterao0 identificados pe"as respectivas sig"as5
- atividades norma"mente e%ecutadas na iterao repartidas de
acordo com os respectivos f"u%os5
- resu"tados da iterao indicando7se nome e sig"a dos artefatos
produ!idos e caso a iterao produ!a apenas partes de um
artefato que partes so estas5
- critrios de aprovao que devem ser satisfeitos para que a
iterao possa ser conc"u#da5
21
21
- normas pertinentes ?s atividades da iterao
As descri&es aqui apresentadas foca"i!am principa"mente os
e"ementos tcnicos do processo. Entretanto os e"ementos gerenciais mais
importantes so indicados agrupando7se as atividades gerenciais em um f"u%o e%tra
de >esto.
8.1.8.; E4e+en'%1 $%1 &4-H%1
6ara representao dos deta"hes de cada f"u%o sero uti"i!ados os
diagramas de atividades da <)O. Estes diagramas so uma variante dos
f"u%ogramas sendo gera"mente usados para descrever processos de neg-cio. Os
f"u%os podem ser encarados como processos de neg-cio dos desenvo"vedores de
software. A ta$e"a 1./3 e%p"ica os s#m$o"os usados.
Tabela 2.13 S:+3%4%1 $%1 $#!g"!+!1 $e !'#5#$!$e1
S:+3%4% De1*"#./%
4et@ngu"o ova"ado Atividade ;passo do f"u%o0
4et@ngu"o O$jeto ;artefato do f"u%o0
'eta cheia 4e"ao de precedncia entre atividades
'eta ponti"hada (onsumo ou produo de o$jeto por atividade
Oinha hori!onta" cheia 6onto de sincroni!ao ;onde su$f"u%os
para"e"os se juntam0
6equeno c#rcu"o cheio Estado inicia"
(#rcu"o cheio dentro de c#rcu"o va!io Estado fina"
8.1.8.= D#1'"#3-#./% $%1 e1&%".%1
O re"acionamento entre f"u%os e fases matricia". A ta$e"a 1./L mostra
para cada co"una uma distri$uio p"aus#ve" do esforo da fase entre os f"u%os. A
ta$e"a 1./M mostra na *"tima "inha uma distri$uio p"aus#ve" do esforo do projeto
por cada fase.
9a$e"a 1./L 7 <ma poss#ve" distri$uio do esforo de cada fase por f"u%o
C%n*e,./% E4!3%"!./% Cn1'"-./% T"!n1#./%
Re9-#1#'%1 WKKK 3MKK 1KK /KK
An24#1e /MKK MMKK MKK 1KK
De1en% 3KK MKK 3KKK /KKK
I+,4e+en'!./% /KK 3KK LMKK 1KKK
Te1'e1 /KK 1KK /WKK STKK
T%'!4 $% &4-H% /KKKK /KKKK /KKKK /KKKK
9a$e"a 1./M 7 distri$uio do esfor5o tota" por fase e f"u%o ;.a"ores em percentua"0
C%n*e,./% E4!3%"!./% Cn1'"-./% T"!n1#./% T%'!4 ,%" &4-H%
Re9-#1#'%1 LKK TKK //K K1K /13K
An24#1e KTM //KK 1TM KLK /LVK
De1en% K/M /KK /SMK 1KK /VSM
I+,4e+en'!./% KKM KSK 1LTM LKK 1VLK
Te1'e1 KKM KLK VVK /3LK 13TM
T%'!4 ,%" &!1e MKK 1KKK MMKK 1KKK /KKKK
22
22
Esses e%emp"os so inteiramente hipotticos mas representam uma
distri$uio ra!ove" para um projeto $em condu!ido. O f"u%o de 4equisitos domina
a (oncepo quando so "evantados os primeiros requisitos e mantm7se durante
a e"a$orao quando e"es so deta"hados e va"idades. O esforo com os requisitos
pequeno nas fases seguintes correspondendo apenas a eventuais corre&es e
comp"ementa&es. O f"u%o de An"ise mais importante na E"a$orao do que na
(oncepo correspondendo nas fases seguintes apenas a eventuais corre&es. Os
f"u%os de 2esenho e Fmp"ementao so pequenos nas fases iniciais
correspondendo apenas ? confeco de prot-tipos5 predominam durante a
(onstruo e na 9ransio correspondem apenas a corre&es de pro$"emas. O
f"u%o de 9estes pesa pouco nas duas primeiras fases correspondendo apenas ao
teste de prot-tipos5 e"e pesa mais na (onstruo e domina a 9ransio.
As fases so divididas em unidades gerenciais menores chamadas de
itera&es. (ada iterao terminada pe"a produo de um conjunto de resu"tados. O
6ra%is pode ser mo"dado a diferentes cic"os de vida variando7se o n*mero de
itera&es por fase. =uando a distri$uio dos esforos entre os f"u%os e do n*mero
de itera&es entre as fases mais $a"anceada apro%ima7se do mode"o em espira". A
distri$uio de esforos e%emp"ificada nas ta$e"as 1./L e 1./M caracter#stica de um
mode"o pr-%imo da entrega evo"utiva que coerente com as itera&es que so
deta"hadas a seguir.
8.0 De'!4e1 $!1 &!1e1
8.0.1 C%n*e,./%
Esudo !ni"ial
A iterao de Ativao ;ta$e"a 1./S0 tem por o$jetivo verificar se o
c"iente tem necessidades de neg-cio suficientes para justificar estudos deta"hados
de especificao de um produto de software que seriam ento rea"i!ados na fase de
E"a$orao. A Ativao natura"mente a menos forma" das itera&es do processo.
)uitas ve!es e"a no co$rada do c"iente sendo assumida pe"o fornecedor como
investimento de risco. 6or isso deve durar o m#nimo necessrio para que se faa
uma ava"iao grosseira do escopo e da via$i"idade de uma idia de produto.
Entretanto deve7se produ!ir informao suficiente para dimensionar a E"a$orao j
que esta gera"mente envo"ve despesas no despre!#veis quer sejam $ancadas pe"o
c"iente ou pe"o fornecedor.
As principais atividades da Ativao fa!em parte do f"u%o de 4equisitos,
a definio do escopo do produto e o "evantamento pre"iminar dos requisitos. X
importante tam$m o f"u%o de >esto que inc"ui o "evantamento das metas
gerenciais ;principa"mente "imites de pra!o e custo aceitveis para o c"iente0 e as
estimativas de custo e pra!o da fase de e"a$orao. Essas estimativas so usadas
para produ!ir uma proposta de Especificao de 'oftware.
>era"mente esses "evantamentos pre"iminares so conseguidos em
poucos dias de negociao com o c"iente mas projetos mais comp"e%os podem
requerer estudos de via$i"idade e confeco de prot-tipos at para uma verificao
m#nima da via$i"idade dos conceitos. X gera"mente interessante fa!er um pequeno
es$oo da arquitetura do produto definindo a estrutura deste em poucos $"ocos e
propondo as tecno"ogias que so mais fortes candidatas a serem usadas no projeto.
2
2
9a$e"a 1./S U S*"#,' $! A'#5!./%
De1*"#./%
Oevantamento e an"ise das necessidades dos usurios e
conceitos da ap"icao em n#ve" de deta"he suficiente para
justificar a especificao de um produto de software
P"GC"e9-#1#'%1 'o"icitao de proposta
In1-+%1 ;s- documentos e%ternos ao projeto0
A'#5#$!$e1
F4-H% T!"e&!1
Re9-#1#'%1
2efinio do escopo do produto
2efinio dos requisitos ;pre"iminar0
An24#1e Estudos de via$i"idade ;opciona"0
De1en%
Es$oo da arquitetura do produto ;opciona"0
Estudos de via$i"idade ;opciona"0
I+,4e+en'!./% 6rototipagem dos requisitos ;opciona"0
Te1'e1
9estes dos prot-tipos dos requisitos
;opciona"0
Ge1'/%
Oevantamento das metas gerenciais
Estimativas da fase de E"a$orao
E"a$orao de proposta de especificao
Re1-4'!$%1 A"'e&!'% S#g4! P!"'e1
6roposta de Especificao
de 'oftware
6E'w
C"#'G"#%1 $e
!,"%5!./%
Aprovao em reviso gerencia"
Aprovao da 6roposta de Especificao de 'oftware pe"o
("iente
N%"+!1
,e"'#nen'e1
6adro de 6roposta de Especificao de 'oftware
:ote7se que a demanda por um projeto de software pode resu"tar de
um outro projeto de maior porte como um estudo de definio de novo produto um
desenho de um sistema informati!ado comp"e%o um projeto pi"oto de ava"iao de
tecno"ogia ou mesmo de so"icita&es de me"horias e modifica&es de uma verso
anterior do produto. :esse caso a iterao de Ativao fa! a ponte entre a origem
da demanda e o novo projeto.
A Ativao deve identificar todas as poss#veis partes interessadas no
produto a ser especificado. O c"iente deve se comprometer a "i$erar representantes
autori!ados de todos os grupos de usurios para participar do tra$a"ho de
E"a$orao.
8.0.0 E4!3%"!./%
!deni#i"a$%o dos ris"os.
&e'ras(
- )asos de uso diri'em odo o pro"esso de desen*ol*imeno
- )asos de uso #orne"em a base da "omuni"a$%o enre "lienes e
desen*ol*edores no plane+ameno do pro+eo
2!
2!
Ao #inal da elabora$%o, de*e-se er os dia'ramas de "lasses, pa"oes e
"asos de uso. -os dia'ramas de "aso de uso, de*emos analisar ris"os, deermininar
prioridades .os mais "omple/os0 e rele*1n"ia.
2s desen*ol*edores podem se senir 3 *onade dando esimai*as, em
pessoas, semanas de rabal4o, de 5uano empo le*ar6 para "onsruir "ada "aso de
uso. Todos os ris"os si'ni#i"ai*os #oram ideni#i"ados, e os maiores s%o
"ompreendidos a7 5ue pono *o"8 sabe "omo preende lidar "om eles.
A fase de E"a$orao iniciada depois que o c"iente aprova a proposta
de Especificao. E"e contm duas itera&es,
8.0.0.1 Le5!n'!+en'% $%1 Re9-#1#'%1
.isa ? captura das necessidades dos usurios em re"ao ao produto
e%pressas na "inguagem desses usurios. Os requisitos devem ser "evantados em
n#ve" to deta"hado quanto necessrio para que c"iente usurios e desenvo"vedores
se ponham de acordo quanto a e"es. Os requisitos j mencionados na 6roposta de
Especificao so revisados sendo gera"mente amp"iados devido ? participao de
um n*mero maior de partes interessadas. 6ara maior eficcia na captura de
requisitos o processo recomenda que esta seja feita atravs de oficinas ;wor8shops0
estruturadas com participao ativa e intensiva de todas as partes interessadas.
6rot-tipos e estados de via$i"idade so feitos quando necessrio. 6or e%emp"o
prot-tipos rpidos e rascunhos de pape" podem ajudar a definir os requisitos das
interfaces de usurio.
Ao fina" do "evantamento dos 4equisitos o corpo da Especificao de
4equisitos deve estar pronto. Os requisitos funcionais so descritos atravs de
casos de uso que formam a primeira viso do )ode"o de An"ise. As interfaces de
usurio do produto so es$oadas apenas o suficiente para definir os respectivos
requisitos evitando7se entrar em deta"hes de desenho. Os casos de uso devem ser
e%pressos em termos de a&es pertinentes ao dom#nio do pro$"ema e no de
deta"hes das interfaces.
>era"mente uma reviso gerencia" suficiente para fechar essa
iterao pois prefer#ve" rea"i!ar uma reviso tcnica forma" apenas quando de
posse do )ode"o de An"ise. Os requisitos "evantados so "anados em um
(adastro dos 4equisitos que posteriormente amarrar os requisitos com os
respectivos e"ementos derivados nos demais f"u%os. Os requisitos cadastrados
devem ser de a"ta qua"idade, corretos precisos comp"etos consistentes
verificveis e modificveis com prioridades re"ativas $em definidas.
8.0.0.0 An24#1e $%1 Re9-#1#'%1
Enquanto o Oevantamento dos 4equisitos foca"i!a a viso que c"iente e
usurios tm dos requisitos de um produto a An"ise dos 4equisitos foca"i!a a viso
dos desenvo"vedores. Entretanto o processo ainda est dentro do espao de
pro$"ema e no dentro do espao de so"u&es. O )ode"o de An"ise usa a notao
orientada a o$jetos para descrever de forma mais precisa os conceitos do dom#nio
da ap"icao que sejam re"evantes para o entendimento deta"hado dos requisitos do
produto. Essa notao usada como notao de mode"agem do pro$"ema
2"
2"
independentemente do uso posterior da tecno"ogia orientada a o$jetos para desenho
e imp"ementao.
9a$e"a 1./TU S*"#,' $! An24#1e $%1 Re9-#1#'%1
De1*"#./%
)ode"agem conceitua" dos e"ementos re"evantes do dom#nio do pro$"ema e
uso desse mode"o para va"idao dos requisitos e p"anejamento deta"hado da
fase de (onstruo
P"GC"e9-#1#'%1 Oevantamento dos requisitos terminado
In1-+%1
An'#g%1 N%5%1
6E'w E4'w U corpo
)A'w U viso de casos de uso
A'#5#$!$e1
F4-H% T!"e&!1
Re9-#1#'%1 4eviso e modificao dos requisitos ;se necessrio0
An24#1e
Fdentificao das c"asses
Fdentificao dos atri$utos e re"acionamentos
4ea"i!ao dos casos de uso
4eviso e iterao
De1en%
Estudos de via$i"idade ;opciona"0
2esenho arquitetPnico
I+,4e+en'!./% 6rototipagem dos requisitos ;opciona"0
Te1'e1 9estes dos prot-tipos dos requisitos ;opciona"0
Ge1'/%
(adastramento dos itens de an"ise no cadastro de
requisitos
6"anejamento do desenvo"vimento
6"anejamento da qua"idade
Re1-4'!$%1
A"'e&!'% S#g4! P!"'e1
)ode"o de An"ise do 'oftware )A'w .iso O-gica
Especificao dos 4equisitos do
'oftware
E4'w Ane%o U "istagem do
mode"o de an"ise
(adastro de 4equisitos do 'oftware (4'w ("asses
)em-ria de 6"anejamento do 6rojeto
do 'oftware
)66'w 9ota"
6"ano de 2esenvo"vimento do
'oftware
62'w 9ota"
6"ano da =ua"idade do 'oftware 6='w 9ota" ;menos deta"hes de
imp"ementao0
C"#'G"#%1 $e
!,"%5!./%
Aprovao em reviso tcnica
Aprovao em auditoria da qua"idade
Aprovao da Especificao dos 4equisitos do 'oftware e do 6"ano de
2esenvo"vimento do 'oftware pe"o c"iente
N%"+!1 ,e"'#nen'e1
6adro de Especificao de 4equisitos de 'oftware
6adro para 6"ano de 2esenvo"vimento de 'oftware
6adro para 6"ano da =ua"idade de 'oftware
As atividades iniciais de An"ise dos 4equisitos "evam ? identificao
de c"asses que representem adequadamente os conceitos e%pressos nos requisitos
e ? desco$erta dos respectivos atri$utos e re"acionamentos. Essa parte da an"ise
fornece o mode"o "-gico de dados ;equiva"ente a um mode"o de entidades e
re"acionamentos0 que pode corresponder ao mode"o conceitua" de um $anco de
dados usado pe"o produto. Essas c"asses so inc"u#das no (adastro dos 4equisitos.
'o ento deta"hadas as responsa$i"idades de cada c"asse definindo7
se as respectivas opera&es. Estas opera&es so usadas para produ!ir as
2#
2#
rea"i!a&es dos casos de uso nas quais os f"u%os dos casos de uso so descritos
em termos de intera&es entre as c"asses identificadas. >era"mente o deta"hamento
das rea"i!a&es dos casos de uso "eva ? desco$erta de am$igDidades omiss&es e
inconsistncias nos requisitos funcionais contri$uindo para o aperfeioamento
destes. 6rot-tipos e estudos de via$i"idade podem comp"ementar a an"ise5 por
e%emp"o um prot-tipo imp"ementado em um sistema de $ancos de dados pode
ajudar a decidir se vive" atender aos requisitos de desempenho especificados
para transa&es com $ancos de dados.
6rovave"mente as atividades gerenciais mais importantes so as que
acontecem nessa iterao. A Especificao dos 4equisitos agora se torna confive"
o suficiente para servir de $ase ao p"anejamento deta"hado do restante do projeto
permitindo confeccionar uma proposta da fase de (onstruo com pra!os e
oramentos firmes. Essa proposta ref"etida em um 6"ano de 2esenvo"vimento.
A"m disso e%iste informao suficiente para p"anejar as atividades de um grupo de
garantia da qua"idade e%pressas dentro de um 6"ano da =ua"idade.
O fechamento dessa iterao de enorme responsa$i"idade pois a
partir daqui o fornecedor estar possive"mente assumindo compromissos de grande
monta e co"ocando a sua reputao em jogo. 6or isso o processo determina a
rea"i!ao dos seguintes procedimentos de contro"e.
- uma reviso tcnica forma" na qua" um grupo de revisores
independentes ;no pertencentes ? equipe responsve" pe"a
E"a$orao0 composto de desenvo"vedores e outros especia"istas
verifica a qua"idade tcnica da Especificao5
- uma auditoria da qua"idade na qua" um grupo de garantia da
qua"idade verifica se essa fase foi condu!ida conforme determinado
pe"o processo5
- uma reviso gerencia" da equipe do fornecedor responsve" pe"a
E"a$orao que verifica se os desenvo"vedores concordam que os
compromissos a serem assumidos com o c"iente so fact#veis em
que se fa! um $a"ano dessa iterao.
+eitas essas revis&es o fornecedor emitir uma proposta de
desenvo"vimento indicando os compromissos de pra!os e custos que sero
assumidos durante a (onstruo e possive"mente durante a 9ransio. Essa
proposta encaminhar a Especificao de 4equisitos e conter a informao do
6"ano de 2esenvo"vimento no todo ou em parte conforme o re"acionamento
com$inado entre c"iente e fornecedor. A pa"avra fina" quanto ao prosseguimento ou
no do projeto ser dada pe"o c"iente com $ase nesses documentos.
2-
2-
8.0.8 C%n1'"-./%
A ess8n"ia da "onsru$%o de um plano en*ol*e esabele"er uma s7rie
de iera$9es para a "onsru$%o das #un"ionalidades, en#ai:ando(
- *is%o ma"ro dos "asos de uso;
- *is%o deal4ada.
<%o re'ras de "ondu$%o da #ase de "onsru$%o(
- di*idir os "asos de uso de a"ordo "om o *alor do ne'="io, em pil4as
de prioridade .ala, m7dia, bai/a0
- >i*idir pelos ris"os
- Esimar o empo para "ada "aso de uso .an6lise, pro+eo,
"odi#i"a$%o, ese, inera$%o, do"umena$%o0
- >eerminar a dura$%o das iera$9es
2s "asos de uso 5ue 8m ala prioridade e?ou ris"o de*em ser raados
na #ase ini"ial. -%o se de*e adiar os ris"o a7 o #inal.
A "onsru$%o elabora o sisema em uma s7rie de iera$9es, "ada
iera$%o 7 um minipro+eo. @o"8 #a: an6lise, pro+eo, "odi#i"a$%o, ese e ine'ra$%o
para os "asos de uso desi'nados para "ada iera$%o.
As iera$9es denro da "onsru$%o ano s%o in"remenais 5uano
ierai*as. As iera$9es s%o in"remenais na #un$%o, "ada iera$%o 7 "onsruAda sobre
os "asos de uso desen*ol*idos nas iera$9es pr7*ias. As iera$9es s%o ierai*as em
ermos da base de "=di'o, "ada iera$%o impli"ar6 5ue al'uns re"4os de "=di'o
e/isenes se+am rees"rios.
8.0.8.1 De1en% In#*#!4
O 2esenho Fnicia" o principa" passo da (onstruo ;ta$e"a 1./W0. <m
desenho $em7feito reso"ve os seguintes pro$"emas,
- produ! uma arquitetura ro$usta estve" e f"e%#ve" que
indispensve" para que o produto tenha a"ta qua"idade e vida "onga5
- produ! interfaces de usurio que tornem o produto fci" de aprender
e de usar de maneira produtiva5
- serve de $ase para o p"anejamento e desenho precisos dos testes
de aceitao5
- esco"he as so"u&es tecno"-gicas mais adequadas para satisfa!er
os requisitos de forma rpida $arata e confive"5
- identifica componentes comerciais ou de projetos anteriores que
possam ser reuti"i!ados redu!indo o esforo de desenvo"vimento5
- decide as quest&es tcnicas importantes para a imp"ementao
dei%ando para a confeco das "i$era&es apenas a rea"i!ao de
deta"hes5
- divide adequadamente o produto em componentes que possam ser
agrupados em um n*mero satisfat-rio de "i$era&es permitindo a
ava"iao precoce por parte dos usurios5
- divide adequadamente o produto em componentes cuja
imp"ementao possa ser dividida efica!mente entre os mem$ros
de uma equipe de desenvo"vedores diminuindo os pra!os de
imp"ementao.
2.
2.
A atividade inicia" de desenho o desenho da arquitetura que a
estrutura arquitetPnica principa" do produto dividindo7o em camadas pacotes "-gicos
e su$sistemas. Essa atividade envo"ve decis&es tcnicas estratgicas identificando7
se tecno"ogias adequadas para a imp"ementao dos su$sistemas e "oca"i!ando
componentes e%ternos reuti"i!veis. O desenho dos su$sistemas determina os
aspectos principais dos componentes maiores do produto e as interfaces entre estes.
O 2esenho das interfaces de usurio ataca os mtodos necessrios
para satisfa!er os requisitos de e%eqDi$i"idade de uso. 2ependendo do peso que
estes requisitos tenham na aceitao do produto pode ca$er aqui a rea"i!ao de
toda uma $ateria de estudos e e%perimentos de e%eqDi$i"idade de uso. 2esenhadas
as interfaces os casos de uso devem ser deta"hados em termos dos e"ementos reais
das interfaces. O tratamento de erros de usurio e outras e%ce&es deve ser
comp"etamente definido. >era"mente o n#ve" de deta"he das interfaces e dos casos
de uso e%igir a mode"agem de"as atravs de diagrama de estado. +ina"mente
devem ser refeitas as rea"i!a&es dos casos de uso em termos das c"asses de
desenho encontradas. Os casos de uso deta"hados fornecem os e"ementos
necessrios para p"anejar e desenhar os testes de aceitao.
O desenho dos dados persistentes identifica as so"u&es mais
adequadas para o acop"amento entre o mode"o interno de desenho que orientado
a o$jetos e a arquitetura de sistemas e%ternos de arma!enamento de dados
persistentes como os $ancos de dados re"acionais. Essas quest&es so
fundamentais para se atingirem a"guns dos mais importantes requisitos funcionais
como os requisitos de desempenho confia$i"idade porta$i"idade e manuteni$i"idade.
O refinamento das c"asses de desenho vai ocorrendo durante essas
atividades aumentando $astante o tamanho do mode"o de desenho se comparado
com o mode"o de an"ise. 6rot-tipos podem ser usados para reso"ver pro$"emas
espec#ficos em gera" "igados aos requisitos no funcionais. >era"mente so
desco$ertas a"gumas fa"has na especificao de requisitos e no mode"o de an"ise
que devem ser corrigidas.
O 2esenho Fnicia" termina quando o produto foi repartido em um
conjunto de su$sistemas com interfaces $em definidas entre si estando $em
entendida a maneira como os casos de uso sero rea"i!ados. 6ode7se ento p"anejar
as "i$era&es definindo7se os su$sistemas e casos de uso que cada uma
imp"ementar. Os p"anos de desenvo"vimento e da qua"idade devem ser revistos
para co$rir os deta"hes de recursos custos e pra!os dessas "i$era&es.
Os procedimentos de contro"e do 2esenho Fnicia" compreendem,
- aprovao dos aspectos tcnicos do desenho registrados na
2escrio do 2esenho do 'oftware em reviso tcnica5
- aprovao do desenho das interfaces de usurio ;documentado na
2escrio do 2esenho do 'oftware0 pe"os usurios chaves5
- aprovao da conformidade com o processo em auditoria da
qua"idade5
- aprovao do gerente do projeto e da equipe em reviso gerencia"
em que feito o $a"ano da iterao.
2/
2/
9a$e"a 1./WU S*"#,' $% De1en% In#*#!4
De1*"#./%
2efinio interna e e%terna dos componentes de um produto de software em
n#ve" suficiente para decidir as principais quest&es de arquitetura e tecno"ogia e
para permitir o p"anejamento deta"hado das atividades de imp"ementao
P"GC"e9-#1#'%1 E"a$orao terminada
In1-+%1
An'#g%1 N%5%1
)A'w5 E4'w5 (4'w )66'w5 62'w56='w
A'#5#$!$e1
F4-H% T!"e&!1
An24#1e 4eviso e modificao do mode"o de an"ise ;se necessrio0
De1en%
2esenho dos su$sistemas
2esenho do acesso a dados persistentes
2esenho das interfaces de usurio
E"a$orao dos casos de uso de desenho
2esenho das "i$era&es
I+,4e+enC
'!./%
6rototipagem de pro$"emas de desenho ;opciona"0
Te1'e1 6"anejamento e desenho dos testes de aceitao
Ge1'/%
(adastramento itens de teste 7 cadastro de requisitos
(adastramento itens de desenho 7 cadastro requisitos
6"anejamento deta"hado das "i$era&es
Atua"i!ao dos p"anos de desenvo"vimento e da qua"idade
Re1-4'!$%1
A"'e&!'% S#g4! P!"'e1
Fnsumos Eventuais modifica&es e
deta"hes adicionais
)ode"o de 2esenho do 'oftware )2'w 9odas as vis&es em
descrio de a"to n#ve"
2escrio do 2esenho do 'oftware 22'w 6artes / a L com co"ocao
no ane%o das partes j
produ!idas do )2'w
2escrio dos 9estes do 'oftware 29'w 6"anos e especifica&es dos
testes de aceitao
Nateria de 9estes de 4egresso do
'oftware
N94'w 'cript para automao dos
testes de aceitao
;opciona"0
C"#'G"#%1 $e
!,"%5!./%
Aprovao em reviso tcnica
Aprovao do desenho das interfaces de usurio pe"os usurios chaves
N%"+!1 ,e"'#nen'e1
6adro para 2escrio de 2esenho de 'oftware
6adro para 2ocumentao de 9estes de 'oftware
8.0.8.0 L#3e"!./%
A ta$e"a 1./V apresenta o script de uma Oi$erao t#pica. O desenho
deta"hado reso"ve os aspectos fa"tantes das unidades que sero imp"ementadas
nessa "i$erao como nomes de todas as unidades assinaturas e visi$i"idade das
opera&es imp"ementao dos re"acionamentos quest&es de escopo tratamento de
erros e e%ce&es a"goritmos e estrutura de dados. A "-gica de cada unidade
deta"hada atravs de mquinas de estados pseudo"inguagem e outros meios.
0
0
9a$e"a 1./VU S*"#,' $! L#3e"!./% n
De1*"#./%
Fmp"ementao de um su$conjunto de fun&es do produto que ser ava"iado
pe"os usurios
P"GC"e9-#1#'%1
2esenho Fnicia" terminado
Oi$erao anterior terminada e ava"iada pe"os usurios
In1-+%1
An'#g%1 N%5%1
)A'w5 E4'w5 (4'w5 )66'w5
62'w5 6='w5 )2'w5 22'w5 29'w5
N94'w5
(+'w ;"i$erao anterior05 (E'w
;"i$erao anterior05 49'w ;"i$erao
anterior0
A'#5#$!$e1
F4-H% T!"e&!1
De1en% 4eviso e modificao do mode"o de desenho ;se necessrio0
I+,4e+enC
'!./%
2esenho deta"hado dos componentes desta "i$erao
(odificao dos componentes desta "i$erao
(ompi"ao dos componentes deste "i$erao
Te1'e1
6"anejamento e desenho dos testes de integrao da "i$erao
6"anejamento e desenho dos testes de unidade da "i$erao
4ea"i!ao do testes de unidade da "i$erao
4ea"i!ao dos testes de integrao da "i$erao
Ge1'/%
4eviso e modificao dos p"anos de desenvo"vimento e da
qua"idade ;se necessrio0
Re1-4'!$%1
A"'e&!'% S#g4! P!"'e1
deta"hes adicionais
4e"at-rio dos 9estes do 'oftware 49'w 4e"at-rios dos testes de
unidade e de integrao da
"i$erao ;opciona"0
(-digos +ontes do 'oftware (+'w <nidades da "i$erao
Estruturas provis-rias de
teste
(-digos E%ecutveis do 'oftware (E'w <nidades da "i$erao
Estruturas provis-rias de
teste
C"#'G"#%1 $e
!,"%5!./%
Yprovao em inspeo do desenho deta"hado e c-digo da "i$erao
Aprovao da "i$erao pe"os usurios chaves
N%"+!1 ,e"'#nen'e1
6adro para 2escrio de 2esenho de 'oftware
6adro para 2esenho 2eta"hado e (odificao de 'oftware
Os testes de integrao so p"anejados e desenhados gera"mente
aproveitando7se su$conjuntos adequados dos testes de aceitao. A definio das
interfaces e da "-gica interna das unidades permite o desenho dos respectivos
testes. O conjunto do desenho deta"hado su$metido a uma inspeo. 2urante a
codificao. O c-digo inspecionado verificando7se sua conformidade tanto com o
desenho deta"hado quanto com o padro de codificao. Em seguida o c-digo novo
compi"ado e os testes de unidade so e%ecutados possive"mente com o au%#"io de
estruturas provis-rias de teste.
:a integrao da "i$erao o c-digo novo "igado com os
componentes produ!idos nas "i$era&es anteriores e com os componentes e%ternos
1
1
necessrios. O conjunto su$metido aos testes de integrao. <ma ve! e%ecutve"
a "i$erao su$metida ? ava"iao dos usurios. >era"mente so desco$ertos
a"guns pro$"emas que "evam a refa!er a"guns aspectos do desenho e
possive"mente da an"ise e dos requisitos.
Os procedimentos de contro"e cada "i$erao compreendem,
- inspeo do desenho deta"hado e do c-digo das novas unidades da
"i$erao5
- aprovao da "i$erao pe"os usurios chaves5
- aprovao da conformidade com o processo e dos resu"tados dos
testes em Auditoria da =ua"idade5
- aprovao do gerente do projeto e da equipe em 4eviso >erencia"
onde feito o $a"ano da iterao.
8.0.8.8 Te1'e1 A4&!
9a$e"a 1.1KU S*"#,' $%1 Te1'e1 A4&!
De1*"#./%
4ea"i!ao dos testes de aceitao no am$iente dos desenvo"vedores
juntamente com e"a$orao da documentao de usurio e poss#veis p"anos de
9ransio
P"GC"e9-#1#'%1 Z"tima "i$erao terminada e ava"iada pe"os usurios
In1-+%1
An'#g%1 N%5%1
)A'w5 E4'w5 (4'w5 )66'w5
62'w5 6='w5 )2'w5 22'w5 29'w5
N94'w5
(+'w ;*"tima "i$erao05 (E'w ;*"tima
"i$erao05 49'w ;*"tima "i$erao0
A'#5#$!$e1
F4-H% T!"e&!1
De1en% 4eviso e modificao do desenho de a"to n#ve" ;se necessrio0
I+,4e+enC
'!./%
4eviso e modificao do desenho deta"hado e c-digo ;se
nececessrio0
6roduo da documentao de usurio
Te1'e1
4ea"i!ao dos testes a"fa ;aceitao no am$iente dos
desenvo"vedores0
Ge1'/%
6"anejamento deta"hado da 9ransio
Atua"i!ao dos p"anos de desenvo"vimento e da qua"idade
Re1-4'!$%1
A"'e&!'% S#g4! P!"'e1
deta"hes adicionais
4e"at-rio dos 9estes do 'oftware 49'w 4e"at-rios dos testes a"ta
)anua" do <surio do 'oftware )<'w
C"#'G"#%1 $e
!,"%5!./%
Aprovao da entrega do produto pe"o c"iente
N%"+!1 ,e"'#nen'e1
6adro para 2ocumentao de <surio de 'oftware
A iterao dos 9estes A"fa ;ta$e"a 1.1K0 fecha a (onstruo. Os testes
de aceitao so rea"i!ados no am$iente do fornecedor em$ora seja recomendve"
que isso seja feito por uma equipe especia"i!ada em testes independentemente dos
desenvo"vedores. 2urante os testes so identificados pro$"emas remanescentes. 'e
os pro$"emas identificados corresponderem a defeitos de desenho ou de requisitos
2
2
as corre&es necessrias devem ser feitas no s- no c-digo mas em toda a cadeia
de artefatos afetada. O (adastro de 4equisitos se adequadamente mantido
permitir identificar quais os itens afetados dessa cadeia.
:essa iterao e"a$orado o materia" de suporte ? 9ransio. O
principa" item deste o )anua" do <surio no qua" os procedimentos dos usurios
podem ser descritos a partir dos casos de uso deta"hados e outros aspectos do
desenho das interfaces de usurios. A documentao de usurio pode inc"uir outros
itens de treinamento promoo e suporte como demonstra&es e s#tios de apoio.
A"m disso se a 9ransio envo"ver um grande n*mero de insta"a[&es ou
procedimentos comp"e%os recomendve" acrescentar ao p"ano de
desenvo"vimento um p"ano de transio.
:o encerramento dos testes a"fa no so previstas revis&es tcnicas
espec#ficas mas apenas uma auditoria da qua"idade que checar inc"usive os
resu"tados dos testes de aceitao documentos nos respectivos re"at-rios. O
produto ento entregue ao c"iente para imp"antao nas insta"a&es da fase de
9ransio.
8.0.; T"!n1#./%
8.0.;.1 Te1'e1 Ie'!
9a$e"a 1.1/U S*"#,' $%1 Te1'e1 Ie'!
De1*"#./% 4ea"i!ao dos testes de aceitao no am$iente dos usurios
P"GC"e9-#1#'%1
(onstruo terminada
Aceitao da insta"ao do produto pe"o c"iente
In1-+%1
An'#g%1 N%5%1
)A'w5 E4'w5 (4'w5 )66'w5
62'w5 6='w5 )2'w5 22'w5 29'w5
N94'w5
49'w ;testes a"fa05 )<'w
A'#5#$!$e1
F4-H% T!"e&!1
I+,4e+enC
'!./%
nececessrio0
4eviso e modificao da documentao de usurio ;se
necessrio0
Te1'e1 4ea"i!ao dos testes $eta ;aceitao no am$iente dos usurios0
Ge1'/%
Re1-4'!$%1
A"'e&!'% S#g4! P!"'e1
deta"hes adicionais
4e"at-rio dos 9estes do 'oftware 49'w 4e"at-rios dos testes $eta
C"#'G"#%1 $e
!,"%5!./%
Aprovao dos testes $eta pe"o c"iente
N%"+!1 ,e"'#nen'e1 6adro para 2ocumentao de 9este de 'oftware
:os 9estes Neta ;ta$e"a 1.1/0 os testes de aceitao so repetidos

nas insta"a&es dos usurios. 6ro$"emas re"acionados com o funcionamento em
insta"a&es reais so identificados e reso"vidos. A documentao de usurio tam$m
testada. A aprovao da iterao inc"ui o contro"e pe"o fornecedor ;atravs de
Auditoria da =ua"idade e 4eviso >erencia"0 e pe"o c"iente ;que ao aprovar os
9estes Neta autori!a o in#cio da Operao 6i"oto0.
8.0.;.0 O,e"!./% P#4%'%
A Operao 6i"o ;ta$e"a 1.110 representa um estado de A"i$erdade
vigiadaC do produto. Em sistemas de misso cr#tica essa iterao ser rea"i!ada
inicia"mente em insta"a&es esco"hidas como pi"otos tomando7se os devidos
cuidados em re"ao a $ac8ups segurana e treinamento dos operadores. Os
pro$"emas encontrados pe"os usurios passam a ser tratados pe"o processo de
manuteno do produto permitindo7se ava"iar a qua"idade dos servios de
manuteno e suporte ao usurio. Os registros de defeitos permitem uma primeira
ava"iao da qua"idade fina" do produto.
9a$e"a 1.11U S*"#,' $! O,e"!./% P#4%'%
De1*"#./% 4ea"i!ao dos testes de aceitao no am$iente dos usurios
P"GC"e9-#1#'%1
(onstruo terminada
Aceitao da insta"ao do produto pe"o c"iente
In1-+%1
An'#g%1 N%5%1
)A'w5 E4'w5 (4'w5 )66'w5
62'w5 6='w5 )2'w5 22'w5 29'w5
N94'w5
49'w ;testes a"fa05 )<'w
A'#5#$!$e1
F4-H% T!"e&!1
I+,4e+enC
'!./%
nececessrio0
4eviso e modificao da documentao de usurio ;se
necessrio0
Te1'e1 4ea"i!ao dos testes $eta ;aceitao no am$iente dos usurios0
Ge1'/%
Re1-4'!$%1
A"'e&!'% S#g4! P!"'e1
deta"hes adicionais
4e"at-rio dos 9estes do 'oftware 49'w 4e"at-rios dos testes $eta
C"#'G"#%1 $e
!,"%5!./%
Aprovao dos testes $eta pe"o c"iente
N%"+!1 ,e"'#nen'e1 6adro para 2ocumentao de 9este de 'oftware
2urante a Operao 6i"oto feita uma an"ise post7mortem do projeto
foca"i!ando os pro$"emas de processo encontrados. Esse $a"ano conso"idado em
um 4e"at-rio +ina" do 6rojeto onde so resumidas as mtricas importantes
!
!
co"etadas no projeto e as "i&es que possam "evar ? me"horia do processo em
projetos futuros.
8.8 A"'e&!'%1
Os resu"tados produ!idos e insumos consumidos nos passos do 6ra%is
so chamados de artefatos do processo. (omo mostra a ta$e"a 1.13 os artefatos
podem ser documentos e mode"os conforme seus consumidores primrios sejam
humanos ou ferramentas.
Tabela 2.23 T#,%1 $e !"'e&!'% $% P"!H#1
T#,% $e !"'e&!'% De1*"#./%
M%$e4% Artefato de uma ferramenta tcnica espec#fica produ!ido e usado nas
atividades de um dos f"u%os do processo
D%*-+en'% Artefato produ!ido por ferramenta de processamento de te%to ou hiperte%to
que pode ser consu"tado on7"ine ou em forma impressa para fins de referncia
ou reviso.
Os artefatos podem ser tam$m permanentes ou transit-rios em
re"ao ao processo. Os artefatos permanentes so atua"i!ados a cada iterao do
processo de acordo com procedimentos de gesto de configura&es. <m conjunto
de artefatos associados a um marco do projeto consistentes entre si e conformes
com os padr&es do processo constitui uma 4#n! $e 3!1e deste projeto. As "inhas
de $ase so tipicamente montadas ao fina" de cada iterao preservando7se assim
um retrato comp"eto do projeto em cada um desses instantes. Fsso muito
importante para faci"itar a "oca"i!ao posterior de defeitos.
Tabela 2.24 D%*-+en'%1 ,e"+!nen'e1 $% P"!H#1
N%+e S#g4! De1*"#./%
P"%,%1'! $e
E1,e*#&#*!./%
$% S%&'(!"e
6E's 2ocumentos que de"imita pre"iminarmente o escopo de um
projeto contendo um p"ano da fase de E"a$orao
E1,e*#&#*!./%
$%1 Re9-#1#'%1
$% S%&'(!"e
E4'w 2ocumento que descreve de forma deta"hada o conjunto de
requisitos especificados para um produto de software
P4!n% $e
De1en5%45#+en'
% $% S%&'(!"e
62'w 2ocumentos que descreve de forma deta"hada os compromissos
que o fornecedor assume em re"ao ao projeto quanto a
recursos custos pra!os riscos e outros aspectos gerenciais
P4!n% $!
>-!4#$!$e $%
S%&'(!"e
6='w 2ocumentos que descreve de forma deta"hada os procedimentos
de garantia da qua"idade que sero adotados no projeto
De1*"#./% $%
De1en% $%
S%&'(!"e
22'w 2ocumento que descreve de forma deta"hada os aspectos mais
importantes do desenho do software
De1*"#./% $%1
Te1'e1 $%
S%&'(!"e
29'w 2ocumento que descreve de forma deta"hada os p"anos e
especifica&es dos testes que sero e%ecutados
M!n-!4 $%
U1-2"#% $%
S%&'(!"e
)<'w 2ocumento que serve de referncia para uso do produto
"
"
A ta$e"a 1.1L apresenta os documentos permanentes oficiais do pra%is.
Os dois p"anos so considerados documentos gerenciais e os demais so
documentos tcnicos. 9ipicamente e"es so produ!idos atravs de uma ferramenta
de edicE\ao de te%tos. O formato desses documentos conforme com os padr&es do
FEEE ;FEEEVL0. Estes padr&es requerem documentos $astante deta"hados mas o
processo inc"ui ga$aritos que faci"itam o seu preenchimento. A"m disso em a"guns
ga$aritos so preenchidas previamente as partes que no variam muito entre
projetos conformes com esse processo5 assim s- as e%ce&es precisam ser
documentadas.
A ta$e"a 1.1M apresenta os mode"os permanentes do pra%is. A mem-ria
de 6"anejamento do 6rojeto do 'oftware o *nico mode"o gerencia". A *"tima co"una
indica o tipo de ferramenta necessrio para processamento de cada mode"o. Em
a"guns casos so apresentadas a"ternativas de menor ou maior sofisticao
tecno"-gica.
Tabela 2.25 M%$e4%1 ,e"+!nen'e1 $% P"!H#1
N%+e S#g4! De1*"#./% Fe""!+en'!1
!,4#*25e#1
C!$!1'"% $%1
Re9-#1#'%1 $%
S%&'(!"e
(4'w )ode"o que contm os requisitos "evantados
assim como referncias aos itens
correspondentes dos mode"os seguintes
6"ani"ha $anco de
dados
M%$e4% $e An24#1e
$% S%&'(!"e
)A'w )ode"o que deta"ha os conceitos do dom#nio do
pro$"ema a reso"ver que sejam re"evantes para
a va"idao dos requisitos
+erramenta de
mode"agem Orient.
O$jetos
Me+J"#! $e
P4!ne7!+en'% $%
P"%7e'% $% S%&'(!"e
)66'w )ode"o que contm a informao necessria
para o p"anejamento e acompanhamento de
tamanhos esforos custos pra!os e riscos do
projeto
6"ani"ha ferramenta
de gesto de
projetos
I!'e"#! $e Te1'e1
$e Reg"e11/% $%
S%&'(!"e
N94'w (onjunto dos scripts dos testes de regresso +erramenta de
mode"agem
Orientada a O$jetos
CJ$#g%1 F%n'e1 $%
S%&'(!"e
(+'w (onjunto dos c-digos fontes produ!idos +erramenta de
desenvo"vimento
CJ$#g%1
EHe*-'25e#1 $%
S%&'(!"e
(E'w (onjunto dos c-digos e%ecutveis produ!idos +erramenta de
desenvo"vimento
A ta$e"a 1.1S apresenta os re"at-rios do 6ra%is. Os dois primeiros so
de carter tcnico e os demais de carter gerencia". O p"ano da qua"idade prev as
datas de emisso dos re"at-rios de testes revis&es e auditorias. Os re"at-rios de
acompanhamento so produ!idos com a periodicidade especificada no p"ano de
desenvo"vimento ;gera"mente mensa"0.
A ta$e"a 1.1T e 1.1W mostram o re"acionamento entre itera&es e
artefatos. <m 6 indica a iterao inicia" em que um artefato produ!ido5 um ( indica
que o artefato norma"mente comp"etado nessa iterao e um A indica que o
artefato pode ser a"terado na iterao. A partir da An"ise dos 4equisitos cada "inha
indica o conte*do da "inha de $ase de sa#da da iterao.
#
#
Tabela 2.26 Re4!'J"#%1 $% P"!H#1
N%+e S#g4! De1*"#./%
Re4!'J"#% $%1
Te1'e1 $% S%&'(!"e
49'w (onjunto dos re"at-rios que descrevem os resu"tados dos testes
rea"i!ados
Re4!'J"#%1 $e
Re5#1/% $%
S%&'(!"e
44'w (onjunto dos re"at-rios que descrevem as conc"us&es das revis&es
rea"i!adas
Re4!'J"#%1 $!1
A-$#'%"#!1 $!
>-!4#$!$e $%
S%&'(!"e
4A='w (onjunto dos re"at-rios que descrevem as conc"us&es das
auditorias da qua"idade rea"i!adas
Re4!'J"#%1 $e
A*%+,!n!+en'%
$% P"%7e'% $%
S%&'(!"e
4A6'w (onjunto dos re"at-rios de acompanhamento do projeto que
re"atam esforos custos pra!os e riscos do per#odo re"atado
comparados com o que foi p"anejado
Re4!'J"#% F#n!4 $%
P"%7e'% $e S%&'(!"e
4+6'w 4e"at-rio de $a"ano fina" do projeto
Tabela 2.27 Re4!*#%n!+en'% en'"e #'e"!.?e1 e $%*-+en'%1
6E'w E4'w 62'w 6='w 22'w 29'w )<'w
Ativao P
Oevantamento dos
4equisitos
P
An"ise dos 4equisitos C P P
2esenho Fnicia" A A A P P
Oi$erao.. A A A C C
9estes A"fa A A A A A P
9este Neta A A A A A A
Operao 6i"oto A A A A A A
Tabela 2.28 Re4!*#%n!+en'% en'"e #'e"!.?e1 e +%$e4%1
(4'w )A'w )66'w )2'w N94'w (+'w (E'w
Ativao
Oevantamento dos 4equisitos P
An"ise dos 4equisitos C P P
2esenho Fnicia" C A A P P
Oi$erao.. C A A C C P P
9estes A"fa A A A A A A A
9este Neta A A A A A A A
Operao 6i"oto A A A A A A A
Legen$! ,!"! '!3e4!1 0.0K e 0.0L
P Fterao inicia" em que um artefato produ!ido
C Artefato norma"mente comp"etado nessa iterao
-
-
A Artefato pode ser a"terado na iterao
8.; P"%*e$#+en'%1 $e C%n'"%4e
Os procedimentos de contro"e so e%ecutados de maneira uniforme
em diferentes itera&es do cic"o de vida. A conc"uso desses procedimentos
condio necessria para que uma iterao de um projeto seja considerada como
aprovada passando7se ? iterao seguinte. )aiores deta"hes so$rew os diversos
tipos de revis&es so fornecidos no 6adro para 4evis&es.
As "e5#1?e1 'G*n#*!1 so o principa" meio de contro"e da qua"idade
quanto aos aspectos tcnicos5 no caso das "i$era&es usa7se para a reviso de
desenho deta"hado e c-digo a Fnspeo que um procedimento um pouco mais
rigoroso. Os pontos para rea"i!ao das 4evis&es 9cnicas foram definidos
procurando7se equi"i$rar os vrios aspectos envo"vidos como o vo"ume de materia"
su$metido ? reviso o risco a que esto e%postas as atividades su$seqDentes e o
custo das pr-prias revis&es.
:a "e5#1/% ge"en*#!4, o gerente do projeto determina se a atividade
pode ser dada por conc"u#da ouvindo o$rigatoriamente os mem$ros da equipe do
projeto envo"vidos na atividade ou que possam ser afetados por e"a. Em caso
negativo o gerente so"icita ? equipe do projeto que refaa a atividade. Em caso
positivo o gerente do projeto condu! um $a"ano das atividades de iterao e toma
as providncias para a passagem ? pr-%ima iterao. O $a"ano tem por o$jetivo
determinar que "i&es importantes foram aprendidas5 estas podem servir de $ase
para a me"horia do processo em projetos futuros.
As auditorias da qua"idade so tipicamente feitas por um grupo
independente de >arantia da =ua"idade. Este grupo checa principa"mente a
conformidade das atividades rea"i!adas com os padr&es determinados pe"o
processo. E"e no rea"i!a diretamente as revis&es tcnicas inspe&es e testes de
aceitao mas verifica os re"at-rios desses procedimentos. Outras verifica&es
t#picas dessas auditorias so a conformidade com os procedimentos de gesto de
configura&es a coerncia entre os diversos documentos do processo e a
rastrea$i"idade entre os requisitos e os demais artefatos.
A"gumas itera&es requerem aprovao por parte do c"iente ou dos
usurios chaves. As aprova&es do c"iente gera"mente so necessrias em pontos
que envo"vem decis&es de continuar ou no o projeto ;fim da (oncepo e
E"a$orao0 ou aceitao forma" do produto ;fim da (onstruo e 9ransio0. As
ava"ia&es pe"os usurios chaves gera"mente so feitas quando necessrio
verificar7se em determinado estgio de construo o produto atende ?s
necessidades dos usurios. :essas *"timas ava"ia&es visa7se principa"mente a
determinar se os requisitos foram corretamente interpretados pe"os
desenvo"vedores.
.
.
/
/

Engenharia de Software Wilson de Padua Paulo Filho

Enviado por

Direitos autorais:

Formatos disponíveis

Engenharia de Software Wilson de Padua Paulo Filho

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Engenharia de Software Wilson de Padua Paulo Filho

Enviado por

Direitos autorais:

Formatos disponíveis

W WILSON ILSON DE DE P PDUA DUA P PAULA AULA F FILHO ILHO

:a 9a$e"a /./ a (odificao que representa a escrita fina" de um

:os 9estes Neta ;ta$e"a 1.1/0 os testes de aceitao so repetidos

Você também pode gostar