Cap t ulo 1

ENGENHARIA DE SOFTWARE CONCEITOS BSICOS

1. INTRODUO
Nos anos 40, quando se iniciou a evoluo dos sistemas computadorizados, grande
parte dos esforos, e conseqentes custos, era concentrada no desenvolvimento do
hardware, em razo, principalmente das limitaes e dificuldades encontradas na poca !
medida que a tecnologia de hardware foi sendo dominada, as preocupaes se voltaram,
no in"cio dos anos #0, para o desenvolvimento dos sistemas operacionais, onde surgiram
ento as primeiras realizaes destes sistemas, assim como das chamadas linguagens de
programao de alto n"vel, como $%&'&(N e )%*%+, e dos respectivos compiladores (
tend,ncia da poca foi de poupar cada vez mais o usu-rio de um computador de conhecer
profundamente as questes relacionadas ao funcionamento interno da m-quina,
permitindo que este pudesse concentrar seus esforos na resoluo dos pro.lemas
computacionais em lugar de preocupar/se com os pro.lemas relacionados ao
funcionamento do hardware
0- no in"cio dos anos 10, com o surgimento dos sistemas operacionais com
caracter"sticas de multiprogramao, a efici,ncia e utilidade dos sistemas computacionais
tiveram um consider-vel crescimento, para o que contri.u"ram tam.m, de forma .astante
significativa, as constantes quedas de preo do hardware
2ma conseq,ncia deste crescimento foi a necessidade, cada vez maior, de
desenvolver grandes sistemas de software em su.stituio aos pequenos programas
aplicativos utilizados at ento 3esta necessidade, surgiu um pro.lema nada trivial devido
4 falta de e5peri,ncia e 4 no adequao dos mtodos de desenvolvimento e5istentes para
pequenos programas, o que foi caracterizado, ainda na dcada de 10 como a 6crise do
software6, mas que, por outro lado, permitiu o nascimento do termo 67ngenharia de
8oftware6
(tualmente, apesar da constante queda dos preos dos equipamentos, o custo de
desenvolvimento de software no o.edece a esta mesma tend,ncia 9elo contr-rio,
corresponde a uma percentagem cada vez maior no custo glo.al de um sistema
informatizado ( principal razo para isto que a tecnologia de desenvolvimento de
software implica, ainda, em grande carga de tra.alho, os pro:etos de grandes sistemas de
software envolvendo em regra geral um grande n;mero de pessoas num prazo
relativamente longo de desenvolvimento % desenvolvimento destes sistemas realizado,
na maior parte das vezes, de forma 6ad/hoc6, conduzindo a freqentes desrespeitos de
cronogramas e acrscimos de custos de desenvolvimento
% o.:etivo deste curso apresentar propostas de solues 4s questes
relacionadas ao desenvolvimento de software, atravs da transfer,ncia dos principais
conceitos relativos 4 7ngenharia de 8oftware, particularmente no que diz respeito ao uso
de tcnicas, metodologias e ferramentas de desenvolvimento de software
< == <
CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLA
2. PRINCIPAIS ASPECTOS DO SOFTWARE
2.1. Software: defini!o e "ara"ter#$ti"a$
9ode/se definir o software, numa forma cl-ssica, como sendo> 6um conjunto de
instrues que, quando e5ecutadas, produzem a funo e o desempenho dese:ados,
estruturas de dados que permitam que as informaes relativas ao pro.lema a resolver
se:am manipuladas adequadamente e a documentao necess-ria para um melhor
entendimento da sua operao e uso6
7ntretanto, no conte5to da 7ngenharia de 8oftware, o software deve ser visto como
um produto a ser 6vendido6 ? importante dar esta ,nfase, diferenciando os 6programas6
que so conce.idos num conte5to mais restrito, onde o usu-rio ou 6cliente6 o pr@prio
autor No caso destes programas, a documentao associada pequena ou Ana maior
parte das vezesB ine5istente e a preocupao com a e5ist,ncia de erros de e5ecuo no
um fator maior, considerando que o principal usu-rio o pr@prio autor do programa, este
no ter- dificuldades, em princ"pio, na deteco e correo de um eventual 6.ug6 (lm do
aspecto da correo, outras .oas caracter"sticas no so tam.m o.:eto de preocupao
como a porta.ilidade, a fle5i.ilidade e a possi.ilidade de reutilizao
2m produto de software Aou software, como vamos chamar ao longo do cursoB,
por outro lado, sistematicamente destinado ao uso por pessoas outras que os seus
programadores %s eventuais usu-rios podem, ainda, ter formaes e e5peri,ncias
diferentes, o que significa que uma grande preocupao no que diz respeito ao
desenvolvimento do produto deve ser a sua interface, reforada com uma documentao
rica em informaes para que todos os recursos oferecidos possam ser e5plorados de
forma eficiente (inda, os produtos de software devem passar normalmente por uma
e5austiva .ateria de testes, dado que os usu-rios no estaro interessados Ae nem tero
capacidadeB de detectar e corrigir os eventuais erros de e5ecuo
&esumindo, um programa desenvolvido para resolver um dado pro.lema e um
produto de software destinado 4 resoluo do mesmo pro.lema so duas coisas
totalmente diferentes ? @.vio que o esforo e o conseqente custo associado ao
desenvolvimento de um produto sero muito superiores
3entro desta @tica, importante, para melhor caracterizar o significado de software,
importante levantar algumas particularidades do software, quando comparadas a outros
produtos, considerando que o software um elemento l@gico e no f"sico como a maioria
dos produtos>
o software concebido e desenvolvido como resultado de um trabalho de
engenharia e no manufaturado no sentido cl-ssicoC
o software no se desgasta, ou se:a, ao contr-rio da maioria dos produtos, o
software no se caracteriza por um aumento na possi.ilidade de falhas 4 medida
que o tempo passa Acomo acontece com a maioria dos produtos manufaturadosBC
a maioria dos produtos de software concebida inteiramente sob medida,
sem a utilizao de componentes pr/e5istentes
7m funo destas caracter"sticas diferenciais, o processo de desenvolvimento de
software pode desem.ocar um con:unto de pro.lemas, os quais tero influ,ncia direta na
qualidade do produto
'udo isto porque, desde os prim@rdios da computao, o desenvolvimento dos
programas Aou, a programaoB era visto como uma forma de arte, sem utilizao de
metodologias formais e sem qualquer preocupao com a documentao, entre outros
fatores importantes ( e5peri,ncia do programador era adquirida atravs de tentativa e
erro ( verdade que esta tend,ncia ainda se verifica )om o crescimento dos custos de
software Aem relao aos de hardwareB no custo total de um sistema computacional, o
< =D <
CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLA
processo de desenvolvimento de software tornou/se um item de fundamental importEncia
na produo de tais sistemas
( n"vel industrial, algumas questes que caracterizaram as preocupaes com o
processo de desenvolvimento de software foram>
por que o software demora tanto para ser conclu"doF
por que os custos de produo t,m sido to elevadosF
por que no poss"vel detectar todos os erros antes que o software se:a
entregue ao clienteF
por que to dif"cil medir o progresso durante o processo de desenvolvimento
de softwareF
7stas so algumas das questes que a Engenharia de Software pode a:udar a
resolver 7nquanto no respondemos definitivamente a estas questes, podemos levantar
alguns dos pro.lemas que as originam>
raramente, durante o desenvolvimento de um software, dedicado tempo para
coletar dados so.re o processo de desenvolvimento em s"C devido 4 pouca
quantidade deste tipo de informao, as tentativas em estimar a duraoGcusto
de produo de um software t,m conduzido a resultados .astante insatisfat@riosC
alm disso, a falta destas informaes impede uma avaliao eficiente das
tcnicas e metodologias empregadas no desenvolvimentoC
a insatisfao do cliente com o sistema 6conclu"do6 ocorre freqentemente,
devido, principalmente, ao fato de que os pro:etos de desenvolvimento so
.aseados em informaes vagas so.re as necessidades e dese:os do cliente
Apro.lema de comunicao entre cliente e fornecedorBC
a qualidade do software quase sempre suspeita, pro.lema resultante da pouca
ateno que foi dada, historicamente, 4s tcnicas de teste de software Aat
porque o conceito de qualidade de software algo relativamente recenteBC
o software e5istente normalmente muito dif"cil de manter em operao, o que
significa que o custo do software aca.a sendo incrementado significativamente
devido 4s atividades relacionadas 4 manutenoC isto um refle5o da pouca
importEncia dada 4 manuteni.ilidade no momento da concepo dos sistemas
2.2. Software: %ito$ e Rea&idade
? poss"vel apontar, como causas principais dos pro.lemas levantados na seo
anterior, tr,s principais pontos>
a falta de e5peri,ncia dos profissionais na conduo de pro:etos de softwareC
a falta de treinamento no que diz respeito ao uso de tcnicas e mtodos formais
para o desenvolvimento de softwareC
a Hcultura de programaoI que ainda difundida e facilmente aceita por
estudantes e profissionais de )i,ncias da )omputaoC
a incr"vel 6resist,ncia6 4s mudanas Aparticularmente, no que diz respeito ao uso
de novas tcnicas de desenvolvimento de softwareB que os profissionais
normalmente apresentam
7ntretanto, importante ressaltar e discutir os chamados 6mitos e realidades6 do
software, o que, de certo modo, e5plicam alguns dos pro.lemas de desenvolvimento de
software apresentados
< =J <
CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLA
2.2.1. Mit! "# G#$#%&i'(#%t
Mito 1. )S# ' #*+i,# "i!,-# "# +( ('%+'. $#,.#t "# ,'"$-#! # ,$&#"i(#%t! "#
"#!#%/./i(#%t "# !0t1'$#2 #%t3 ' #*+i,# #!t4 ',t' ' #%&'(i%5'$ 6#(
"#!#%/./i(#%t.)
Realidade 1. Ksto verdadeiramente no o suficiente preciso que a equipe aplique
efetivamente os conhecimentos apresentados no manual necess-rio que o que conste
no dado manual reflita a moderna pr-tica de desenvolvimento de software e que este se:a
e5austivo com relao a todos os pro.lemas de desenvolvimento que podero aparecer no
percurso
Mito 2. )A #*+i,# t#( 0#$$'(#%t'! "# "#!#%/./i(#%t "# !0t1'$# "# 7.ti(' 8#$'932 +('
/#: *+# #.#! "i!,-#( "# &(,+t'"$#! "# 7.ti(' 8#$'93.)
Realidade 2. 'er 4 sua disposio o ;ltimo modelo de computador Ase:a ele um mainframe,
estao de tra.alho ou 9)B pode ser .astante confort-vel para o desenvolvedor do
software, mas no oferece nenhuma garantia quanto 4 qualidade do software
desenvolvido Lais importante do que ter um hardware de ;ltima gerao ter ferramentas
para a automatizao do desenvolvimento de software Aas ferramentas )(87B
Mito . )S# "#!#%/./i(#%t " !0t1'$# #!ti/#$ 't$'!'"2 6'!t' '+(#%t'$ ' #*+i,# ,'$'
5%$'$ ,$': "# "#!#%/./i(#%t.)
Realidade . Ksto tam.m dificilmente vai ocorrer na realidade algum disse um dia que
6 acrescentar pessoas em um pro:eto atrasado vai torn-/lo ainda mais atrasado6 3e
fato, a introduo de novos profissionais numa equipe em fase de conduo de um pro:eto
vai requerer uma etapa de treinamento dos novos elementos da equipeC para isto, sero
utilizados elementos que esto envolvidos diretamente no desenvolvimento, o que vai,
conseqentemente, implicar em maiores atrasos no cronograma
2.2.2. Mit! " C.i#%t#
Mito !. )U(' "#!&$i93 6$#/# # 8#$'. "! $#*+i!it! " !0t1'$# ; !+0i&i#%t# ,'$' i%i&i'$
!#+ ,$<#t... ('i$#! "#t'.5#! ,"#( !#$ "#0i%i"! ,!t#$i$(#%t#.)
Realidade !. 7ste um dos pro.lemas que podem conduzir um pro:eto ao fracasso, o
cliente deve procurar definir o mais precisamente poss"vel todos os requisitos importantes
para o software> funes, desempenho, interfaces, restries de pro:eto e critrios de
validao so alguns dos pontos determinantes do sucesso de um pro:eto
Mito ". )O! $#*+i!it! "# ,$<#t (+"'( &%ti%+'(#%t# "+$'%t# !#+ "#!#%/./i(#%t2
('! i!t %3 $#,$#!#%t' +( ,$6.#('2 +(' /#: *+# !0t1'$# ; 0.#=>/#. # ,"#$4 !+,$t'$
0'&i.(#%t# '! '.t#$'9-#!.)
Realidade ". ? verdade que o software fle5"vel Apelo menos mais fle5"vel do que a
maioria dos produtos manufaturadosB 7ntretanto, no e5iste software, por mais fle5"vel
que suporte alteraes de requisitos significativas com adicional zero em relao ao custo
de desenvolvimento % fator de multiplicao nos custos de desenvolvimento do software
devido a alteraes nos requisitos cresce em funo do est-gio de evoluo do pro:eto,
como mostra a figura ==
< =4 <
CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLA
1 #
1." $ % #
%& $ 1&& #
'E()*)+,- 'ESE*.-/.)ME*0- M1*20E*+,-
3
2
S
0
-
(igura 1.1 4 Knflu,ncia das alteraes de requisitos no custo de um sistema
2.2.2. Mit! " P$0i!!i%'.
Mito %. "A,?! ' #"i93 " ,$8$'(' # ' !+' &.&'93 #( 0+%&i%'(#%t2 t$'6'.5 #!t4
t#$(i%'"."
Realidade %. % que ocorre na realidade completamente diferente disto 8egundo dados
o.tidos a partir de e5peri,ncias anteriores, #0 a M0N do esforo de desenvolvimento de um
software despendido ap@s a sua entrega ao cliente AmanutenoB
Mito 5. "E%*+'%t ,$8$'(' %3 #%t$'$ #( 0+%&i%'(#%t2 ; i(,!!>/#. '/'.i'$ ' !+'
*+'.i"'"#."
Realidade 5. Na realidade, a preocupao com a garantia do software deve fazer parte de
todas as etapas do desenvolvimento, sendo que, ao fim de cada uma destas etapas, os
documentos de pro:eto devem ser revisados o.servando critrios de qualidade
Mito 6. )O ,$"+t ' !#$ #%t$#8+# % 0i%'. " ,$<#t ; ,$8$'(' 0+%&i%'%".)
Realidade 6. % programa em funcionamento uma das componentes do softwarealm
do software, um .om pro:eto deve ser caracterizado pela produo de um con:unto
importante de documentos, os quais podem ser identificados com au5"lio da figura =D
'. PARADI(%AS DA EN(EN)ARIA DE SOFTWARE
'.1 Defini!o de En*en+aria de Software
%s pro.lemas apontados nas sees anteriores no sero, claro, resolvidos da
noite para o dia, mas reconhecer a e5ist,ncia dos pro.lemas e defini/los da forma mais
precisa e eficaz so, sem d;vida, um primeiro passo para a sua soluo
< =# <
CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLA
9lano 7specificao
de &equisitos
9ro:eto +istagem
9lano de
'estes
7struturas
de 3ados
9rograma
$uncionando
(igura 1.2 4 )omponentes do software
7m primeiro lugar, preciso estar ciente tam.m de que no e5iste uma
a.ordagem m-gica que se:a a melhor para a soluo destes pro.lemas, mas uma
com.inao de mtodos que se:am a.rangentes a todas as etapas do desenvolvimento de
um software
(lm disto, importante e dese:-vel que estes mtodos se:am suportados por um
con:unto de ferramentas que permita automatizar o desenrolar destas etapas, :untamente
com uma definio clara de critrios de qualidade e produtividade de software 8o estes
aspectos que caracterizam de maneira mais influente a disciplina de Engenharia de
Software
Na literatura, pode/se encontrar diversas definies da 7ngenharia de 8oftware>
)O #!t'6#.#&i(#%t # +! "# !?.i"! ,$i%&>,i! "# #%8#%5'$i' ,'$' *+# !# ,!!'
6t#$ #&%(i&'(#%t# +( !0t1'$# *+# !#<' &%0i4/#. # *+# 0+%&i%#
#0i&i#%t#(#%t# #( (4*+i%'! $#'i!) ON(2 1PQ
@A ',.i&'93 ,$4ti&' " &%5#&i(#%t &i#%t>0i& ,'$' ,$<#t # ' &%!t$+93
"# ,$8$'('! &(,+t'&i%'i! # ' "&+(#%t'93 %#&#!!4$i' A !+' ,#$'93
# ('%+t#%93.B O*oehm, M1Q
@A6$"'8#( !i!t#(4ti&' ,'$' "#!#%/./i(#%t2 ' ,#$'93 # ' ('%+t#%93
"# !0t1'$#B O(fnor, RJQ
@C%<+%t "# (;t"!2 t;&%i&'! # 0#$$'(#%t'! %#&#!!4$i'! A ,$"+93 "#
!0t1'$# "# *+'.i"'"# ,'$' t"'! '! #t','! " &i&. "# /i"' " ,$"+t.B
OSraTowiaT, R#Q
Num ponto de vista mais formal, a 7ngenharia de 8oftware pode ser definida como
sendo a aplicao da ci,ncia e da matem-tica atravs das quais os equipamentos
computacionais so colocados 4 disposio do homem por meio de programas,
procedimentos e documentao associada 3e modo mais o.:etivo, pode/se dizer que a
7ngenharia de 8oftware .usca prover a tecnologia necess-ria para produzir software de
alta qualidade a um .ai5o custo %s dois fatores motivadores so essencialmente a
qualidade e o custo ( qualidade de um produto de software um parEmetro cu:a
< =1 <
CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLA
quantificao no trivial, apesar dos esforos desenvolvidos nesta direo 9or outro
lado, o fator custo pode ser facilmente quantificado desde que os procedimentos de
conta.ilidade tenham sido corretamente efetuados
'.2. %ode&o$ de De$en,o&,i -ent o de $oftware
% resultado de um esforo de desenvolvimento deve resultar normalmente num
produto % processo de desen7ol7imento corresponde ao con:unto de atividades e um
ordenamento destas de modo a que o produto dese:ado se:a o.tido
2m modelo de desen7ol7imento corresponde a uma representao a.strata do
processo de desenvolvimento que vai, em geral, definir como as etapas relativas ao
desenvolvimento do software sero conduzidas e interrelacionadas para atingir o o.:etivo
do desenvolvimento que a o.teno de um produto de software de alta qualidade a um
custo relativamente .ai5o
(s sees que seguem vo descrever alguns dos modelos conhecidos e utilizados
em desenvolvimento de software
C.2.1. O M"#. D+#"' "E8+'
7ste o modelo mais simples de desenvolvimento de software, esta.elecendo uma
ordenao linear no que diz respeito 4 realizao das diferentes etapas )omo mostra a
figura =J, o ponto de partida do modelo uma etapa de Engenharia de Sistemas, onde o
o.:etivo ter uma viso glo.al do sistema como um todo Aincluindo hardware, software,
equipamentos e as pessoas envolvidasB como forma de definir precisamente o papel do
software neste conte5to 7m seguida, a etapa de 1n8lise de Requisitos vai permitir uma
clara definio dos requisitos de software, sendo que o resultado ser- utilizado como
refer,ncia para as etapas posteriores de 9rojeto, 3odificao, 0este e Manuteno
Operao e
Manuteno
Codificao
Projeto
Anlise de
Requisitos
Teste e
Integrao
Engenharia de
iste!as
(igura 1. 4 Klustrao do modelo Uueda dVWgua
% modelo Uueda dVWgua apresenta caracter"sticas interessantes, particularmente
em razo da definio de um ordenamento linear das etapas de desenvolvimento
9rimeiramente, como forma de identificar precisamente o fim de uma etapa e o in"cio da
< =M <
CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLA
seguinte, um mecanismo de certificao Aou revisoB implementado ao final de cada
etapaC isto feito normalmente atravs da aplicao de algum mtodo de validao ou
verificao, cu:o o.:etivo ser- garantir de que a sa"da de uma dada etapa coerente com a
sua entrada Aa qual :- a sa"da da etapa precedenteBKsto significa que ao final de cada
etapa realizada, deve e5istir um resultado Aou sa"daB a qual possa ser su.metida 4
atividade de certificao
7stas sa"das, o.tidas ao final de cada etapa, so vistas como produtos
intermedi-rios e apresentam/se, normalmente, na forma de documentos Adocumento de
especificao de requisitos, documento de pro:eto do sistema, etcB
%utra caracter"stica importante deste modelo que as sa"das de uma etapa so as
entradas da seguinte, o que significa que uma vez definidas, elas no devem, em hip@tese
alguma ser modificadas
3uas diretivas importantes que norteiam o desenvolvimento segundo o modelo
Uueda dVWgua, so>
todas as etapas definidas no modelo devem ser realizadas, isto porque, em
pro:etos de grande comple5idade, a realizao formal destas vai determinar o
sucesso ou no do desenvolvimentoC a realizao informal e impl"cita de algumas
destas etapas poderia ser feita apenas no caso de pro:etos de pequeno porteC
a ordenao das etapas na forma como foi apresentada deve ser rigorosamente
respeitadaC apesar de que esta diretiva poderia ser questionada, a ordenao
proposta pelo modelo, por ser a forma mais simples de desenvolver, tem sido
tam.m a mais adotada a n"vel de pro:etos de software
? importante lem.rar, tam.m que os resultados de um processo de
desenvolvimento de software no devem ser e5clusivamente o programa e5ecut-vel e a
documentao associada 75iste uma quantidade importante de resultados Aou produtos
intermedi-riosB os quais so importantes para o sucesso do desenvolvimento *aseados
nas etapas apresentadas na figura =J, poss"vel listar os resultados m"nimos esperados
de um processo de desenvolvimento .aseado neste modelo> 3ocumento de 7specificao
de &equisitos, 9ro:eto do 8istema, 9lano de 'este e &elat@rio de 'estes, )@digo $inal,
Lanuais de 2tilizao, &elat@rios de &evises
(pesar de ser um modelo .astante popular, pode/se apontar algumas limitaes
apresentadas por este modelo>
o modelo assume que os requisitos so inalterados ao longo do
desenvolvimentoC isto em .oa parte dos casos no verdadeira, uma vez que
nem todos os requisitos so completamente definidos na etapa de an-liseC
muitas vezes, a definio dos requisitos pode conduzir 4 definio do hardware
so.re o qual o sistema vai funcionarC dado que muitos pro:etos podem levar
diversos anos para serem conclu"dos, esta.elecer os requisitos em termos de
hardware um tanto temeroso, dadas as freqentes evolues no hardwareC
o modelo impe que todos os requisitos se:am completamente especificados
antes do prosseguimento das etapas seguintesC em alguns pro:etos, 4s vezes
mais interessante poder especificar completamente somente parte do sistema,
prosseguir com o desenvolvimento do sistema, e s@ ento encaminhar os
requisitos de outras partesC isto no previsto a n"vel do modeloC
as primeiras verses operacionais do software so o.tidas nas etapas mais
tardias do processo, o que na maioria das vezes inquieta o cliente, uma vez que
ele quer ter acesso r-pido ao seu produto
3e todo modo, pode vir a ser mais interessante a utilizao deste modelo para o
desenvolvimento de um dado sistema do que realizar um desenvolvimento de maneira
totalmente an-rquica e informal
< =R <
CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLA
C.2.2. P$tti,'93
% o.:etivo da 9rototipao um modelo de processo de desenvolvimento que
.usca contornar algumas das limitaes e5istentes no modelo Uueda dVWgua ( idia por
tr-s deste modelo eliminar a pol"tica de 6congelamento6 dos requisitos antes do pro:eto
do sistema ou da codificao
Ksto feito atravs da o.teno de um prot@tipo, com .ase no conhecimento dos
requisitos iniciais para o sistema % desenvolvimento deste prot@tipo feito o.edecendo 4
realizao das diferentes etapas :- mencionadas, a sa.er, a an-lise de requisitos, o
pro:eto, a codificao e os testes, sendo que no necessariamente estas etapas se:am
realizadas de modo muito e5pl"cito ou formal
7ste prot@tipo pode ser oferecido ao cliente em diferentes formas, a sa.er>
prot@tipo em papel ou modelo e5ecut-vel em 9) retratando a interface homem/
m-quina capacitando o cliente a compreender a forma de interao com o
softwareC
um prot@tipo de tra.alho que implemente um su.con:unto dos requisitos
indicadosC
um programa e5istente ApacoteB que permita representar todas ou parte das
funes dese:adas para o software a construir
)olocado 4 disposio do cliente, o prot@tipo vai a:ud-/lo a melhor compreender o
que ser- o sistema desenvolvido (lm disso, atravs da manipulao deste prot@tipo,
poss"vel validar ou reformular os requisitos para as etapas seguintes do sistema
7ste modelo, ilustrado na figura =4, apresenta algumas caracter"sticas
interessantes, tais como>
um modelo de desenvolvimento interessante para alguns sistemas de grande
porte os quais representem um certo grau de dificuldade para e5primir
rigorosamente os requisitosC
atravs da construo de um prot@tipo do sistema, poss"vel demonstrar a
realiza.ilidade do mesmoC
poss"vel o.ter uma verso, mesmo simplificada do que ser- o sistema, com um
pequeno investimento inicial
1n8lise de
Requisitos
9rojeto
3odificao
0este
9rojeto 3odificao 0este
1n8lise de
Requisitos
(igura 1.! 4 7squema de evoluo da prototipao
%s prot@tipos no so sistemas completos e dei5am, normalmente, a dese:ar em
alguns aspectos 2m destes aspectos normalmente a interface com o usu-rio %s
esforos de desenvolvimento so concentrados principalmente nos algoritmos que
implementem as principais funes associadas aos requisitos apresentados, a interface
< =P <
CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLA
sendo, a este n"vel parte suprflua do desenvolvimento, o que permite caracterizar esta
etapa por um custo relativamente .ai5o
9or outro lado, a e5peri,ncia adquirida no desenvolvimento do prot@tipo vai ser de
e5trema utilidade nas etapas posteriores do desenvolvimento do sistema real, permitindo
reduzir certamente o seu custo, resultando tam.m num sistema melhor conce.ido
C.2.C. D#!#%/./i(#%t It#$'ti/
7ste modelo tam.m foi conce.ido com .ase numa das limitaes do modelo
Uueda dVWgua e com.inar as vantagens deste modelo com as do modelo 9rototipao (
idia principal deste modelo, ilustrada na figura =#, a de que um sistema deve ser
desenvolvido de forma incremental, sendo que cada incremento vai adicionando ao
sistema novas capacidades funcionais, at a o.teno do sistema final, sendo que, a cada
passo realizado, modificaes podem ser introduzidas
2ma vantagem desta a.ordagem a facilidade em testar o sistema, uma vez que a
realizao de testes em cada n"vel de desenvolvimento , sem d;vida, mais f-cil do que
testar o sistema final (lm disso, como na 9rototipao, a o.teno de um sistema,
mesmo incompleto num dado n"vel, pode oferecer ao cliente interessantes informaes
que sirvam de su.s"dio para a melhor definio de futuros requisitos do sistema
No primeiro passo deste modelo uma implementao inicial do sistema o.tida, na
forma de um su.con:unto da soluo do pro.lema glo.al 7ste primeiro n"vel de sistema
deve contemplar os principais aspectos que se:am facilmente identific-veis no que diz
respeito ao pro.lema a ser resolvido
2m aspecto importante deste modelo a criao de uma lista de controle de
projeto, a qual deve apresentar todos os passos a serem realizados para a o.teno do
sistema final 7la vai servir tam.m para se medir, num dado n"vel, o quo distante se est-
da ;ltima iterao )ada iterao do modelo de 3esenvolvimento Kterativo consiste em
retirar um passo da lista de controle de pro:eto atravs da realizao de tr,s etapas> o
pro:eto, a implementao e a an-lise % processo avana, sendo que a cada etapa de
avaliao, um passo retirado da lista, at que a lista este:a completamente vazia ( lista
de controle de pro:eto gerencia todo o desenvolvimento, definindo quais tarefas devem ser
realizadas a cada iterao, sendo que as tarefas na lista podem representar, inclusive,
redefinies de componentes :- implementados, em razo de erros ou pro.lemas
detectados numa eventual etapa de an-lise
9rojeto
)mplementao
1n8lise
1
9rojeto
)mplementao
1n8lise
&
9rojeto
)mplementao
1n8lise
*
(igura 1." 4 % modelo 3esenvolvimento Kterativo
C.2.F. O M"#. E!,i$'.
7ste modelo, proposto em =PRR, sugere uma organizao das atividades em
espiral, a qual composta de diversos ciclos )omo mostrado na figura =1, a dimenso
vertical representa o custo acumulado na realizao das diversas etapasC a dimenso
angular representa o avano do desenvolvimento ao longo das etapas
< ==0 <
CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLA
)ada ciclo na espiral inicia com a identificao dos o.:etivos e as diferentes
alternativas para se atingir aqueles o.:etivos assim como as restries impostas % pr@5imo
passo no ciclo a avaliao das diferentes alternativas com .ase nos o.:etivos fi5ados, o
que vai permitir tam.m definir incertezas e riscos de cada alternativa No passo seguinte,
o desenvolvimento de estratgias permitindo resolver ou eliminar as incertezas levantadas
anteriormente, o que pode envolver atividades de prototipao, simulao, avaliao de
desempenho, etc $inalmente, o software desenvolvido e o plane:amento dos pr@5imos
passos realizado
( continuidade do processo de desenvolvimento definida como funo dos riscos
remanescentes, como por e5emplo, a deciso se os riscos relacionados ao desempenho
ou 4 interface so mais importantes do que aqueles relacionados ao desenvolvimento do
programa )om .ase nas decises tomadas, o pr@5imo passo pode ser o desenvolvimento
de um novo prot@tipo que elimine os riscos considerados
9or outro lado, caso os riscos de desenvolvimento de programa se:am considerados
os mais importantes e se o prot@tipo o.tido no passo corrente :- resolve .oa parte dos
riscos ligados a desempenho e interface, ento o pr@5imo passo pode ser simplesmente a
evoluo segundo o modelo Uueda dVWgua
)omo se pode ver, o elemento que conduz este processo essencialmente a
considerao so.re os riscos, o que permite, de certo modo, a adequao a qualquer
pol"tica de desenvolvimento A.aseada em especificao, .aseada em simulao, .aseada
em prot@tipo, etcB
Prot"tipo #
Conceito de
Operao
Plano de Requisitos
Plano de Ciclo
de $ida
Re%iso
Anlise
de Riscos
Anlise
de Riscos
Anlise
de Riscos
Prot"&
tipo '
Prot"&
tipo (
Prot"&
tipo
i!ula)es* !odelos* +++
Requisitos
de oft,are
Requisitos
$alidao dos
-esen%ol%i!ento
Plano de
Integrao e Testes
Plano de
ficao do Pro&
$alidao e $eri&
jeto
Projeto
do pro&
duto de
soft,are
Opera&
cional
Projeto
-etalha&
do
C"digo
Teste
de
uni&
dade
Inte&
grao
e teste
Teste
de acei&
tao
I!ple&
!enta&
o
Prximas etapas
do plano
Avalia alternativas,
identifica e resolve
riscos
Desenvolve e verifica
Produto do Prximo
Nvel
Determina objetivos
alternativas e restries
Anlise
de Riscos
CU!" ACU#U$AD"
A%AN&"
(igura 1.5 4 % modelo espiral
2ma caracter"stica importante deste modelo o fato de que cada ciclo encerrado
por uma atividade de reviso, onde todos os produtos do ciclo so avaliados, incluindo o
plano para o pr@5imo passo Aou cicloB Numa aplicao t"pica do modelo, pode/se imaginar
a realizao de um ciclo zero, onde se avalie a realiza.ilidade do pro:eto, o resultado
devendo ser a concluso de que ser- poss"vel implementar ou no o pro:eto de
desenvolvimento (s alternativas consideradas neste caso so de muito alto n"vel, como
< === <
CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLA
por e5emplo, se a organizao deve desenvolver o sistema ela pr@pria ou se deve
contratar o desenvolvimento :unto a uma empresa especializada
% modelo se adequa principalmente a sistemas que representem um alto risco de
investimento para o cliente
.. /ISO (ERA0 DA EN(EN)ARIA DE SOFTWARE
(nalisando os modelos apresentados na seo precedente, poss"vel o.servar
que, apesar de apresentar denominaes 4s vezes diferentes e de estarem associadas de
modo relativamente distinto, as etapas apresentadas so caracterizadas por atividades
similares
3e um modo geral, pode/se organizar o processo de desenvolvimento de um
software a partir de tr,s grandes fases> a fase de definio, a fase de desen7ol7imento e
a fase de manuteno as quais sero discutidas nas sees a.ai5o
..1. Fa$e de Defini!o
( fase de definio est- associada 4 determinao do que vai ser feito Nesta fase,
o profissional encarregado do desenvolvimento do software deve identificar as informaes
que devero ser manipuladas, as funes a serem processadas, qual o n"vel de
desempenho dese:ado, que interfaces devem ser oferecidas, as restries do pro:eto e os
critrios de validao Ksto ter- de ser feito no importando o modelo de desenvolvimento
adotado para o software e independente da tcnica utilizada pra faz,/lo
7sta fase caracterizada pela realizao de tr,s etapas espec"ficas>
a 1n8lise :ou 'efinio; do Sistema, a qual vai permitir determinar o papel de
cada elemento Ahardware, software, equipamentos, pessoasB no sistema, cu:o
o.:etivo determinar, como resultado principal, as funes atri.u"das ao
softwareC
o 9lanejamento do 9rojeto de Software, no qual, a partir da definio do
escopo do software, ser- feita uma an-lise de riscos e a definio dos recursos,
custos e a programao do processo de desenvolvimentoC
a 1n8lise de Requisitos, que vai permitir determinar o con:unto das funes a
serem realizadas assim como as principais estruturas de informao a serem
processadas
..2. Fa$e de De$en,o&,i -ent o
Nesta fase, ser- determinado como realizar as funes do software (spectos
como a arquitetura do software, as estruturas de dados, os procedimentos a serem
implementados, a forma como o pro:eto ser- transformado em linguagem de programao,
a gerao de c@digo e os procedimentos de teste devem ser encaminhados nesta fase
Normalmente, esta fase tam.m organizada em tr,s principais etapas>
o 9rojeto de Software, o qual traduz, num con:unto de representaes gr-ficas,
ta.ulares ou te5tuais, os requisitos do software definidos na fase anteriorC estas
representaes Adiversas tcnicas de representao podem ser adotadas num
mesmo pro:etoB permitiro definir, com um alto grau de a.strao, aspectos do
software como a arquitetura, os dados, l@gicas de comportamento AalgoritmosB e
caracter"sticas da interfaceC
a 3odificao, onde as representaes realizadas na etapa de pro:eto sero
mapeadas numa ou em v-rias linguagens de programao, a qual ser-
caracterizada por um con:unto de instrues e5ecut-veis no computadorC nesta
etapa, considera/se tam.m a gerao de c@digo de implementao, aquele
< ==D <
CAP. 1 ENGENHARIA DE SOFTWARE: CONCEITOS BSICOS PROF. VITRIO BRUNO MAZZOLA
o.tido a partir do uso de ferramentas Acompiladores, linTers, etcB e que ser-
e5ecutado pelo hardware do sistemaC
os 0estes de Software, onde o programa o.tido ser- su.metido a uma .ateria
de testes para verificar Ae corrigirB defeitos relativos 4s funes, l@gica de
e5ecuo, interfaces, etc
..'. Fa$e de %an1ten!o
( fase de manuteno, que se inicia a partir da entrega do software,
caracterizada pela realizao de alteraes de naturezas as mais diversas, se:a para
corrigir erros residuais da fase anterior, para incluir novas funes e5igidas pelo cliente, ou
para adaptar o software a novas configuraes de hardware
8endo assim, pode/se caracterizar esta fase pelas seguintes atividades>
a 3orreo ou Manuteno 3orreti7a, a qual consiste da atividade de correo
de erros o.servados durante a operao do sistemaC
a 1daptao ou Manuteno 1daptati7a, a qual realiza alteraes no software
para que ele possa ser e5ecutado so.re um novo am.iente A)92, arquitetura,
novos dispositivos de hardware, novo sistema operacional, etcBC
o Melhoramento (uncional ou Manuteno 9erfecti7a, onde so realizadas
alteraes para melhorar alguns aspectos do software, como por e5emplo, o seu
desempenho, a sua interface, a introduo de novas funes, etc
( manuteno do software envolve, normalmente, etapas de an-lise do sistema
e5istente Aentendimento do c@digo e dos documentos associadosB, teste das mudanas,
teste das partes :- e5istentes, o que a torna uma etapa comple5a e de alto custo
(lm disso, considerando a atual situao industrial, foi criado, mais recentemente,
o conceito de Engenharia Re7ersa, onde, atravs do uso das tcnicas e ferramentas da
7ngenharia de 8oftware, o software e5istente sofre uma 6reforma geral6, cu:o o.:etivo
aumentar a sua qualidade e atualiz-/lo com respeito 4s novas tecnologias de interface e de
hardware
< ==J <