Modulo IV

Introduo Engenharia de Software

Pedro de Alcntara dos Santos Neto











































































FICHA BIBLIOGRFICA

PRESIDENTE DA REPBLICA
Luiz Incio Lula da Silva

MINISTRO DA EDUCAO
Fernando Haddad

GOVERNADOR DO ESTADO DO PIAU
Wellington Dias

UNIVERSIDADE FEDERAL DO PIAU
Luiz de Sousa Santos Jnior

SECRETRIO DE EDUCAO A DISTNCIA DO MEC
Carlos Eduardo Bielschowsky

COORDENADORIA GERAL DA UNIVERSIDADE ABERTA DO BRASIL
Celso Costa

SECRETRIO DE EDUCAO DO ESTADO DO PIAU
Antnio Jos Medeiro

COORDENADOR GERAL DO CENTRO DE EDUCAO ABERTA A
DISTNCIA DA UFPI
Gildsio Guedes Fernandes

SUPERITENDENTE DE EDUCAO SUPERIOR NO ESTADO
Eliane Mendona

CENTRO DE CIENCIAS DA NATUREZA
Helder Nunes da Cunha

COORDENADOR DO CURSO DE SISTEMA DE INFORMAO NA
MODALIADE DE EAD
Carlos Andr Bastista de Carvalho

COORDENADORA DE MATERIAL DE DIDTICO DO CEAD/UFPI
Cleidinalva Maria Barbosa Oliveira

DIAGRAMAO
Joaquim Carvalho de Aguiar Neto





Os Sistemas de Informao (SI) so produtos de software
cada vez mais importante no dia-a-dia das pessoas. Tais sistemas
so usualmente compostos por muitos elementos que operam juntos
para recuperar, processar, armazenar e distribuir informao, que
normalmente utilizada para auxiliar a anlise e tomada de deciso
em uma organizao. Por conta disso necessrio o uso de
mtodos, tcnicas e ferramentas para sua construo, para que
possamos obter altos nveis de qualidade a baixos custos.
Nesta apostila apresentamos uma introduo Engenharia de
Software que rea da Computao que aborda a construo de
software, incluindo os Sistemas de Informao, como um produto de
Engenharia.
Na Unidade I apresentamos as origens da Engenharia de
Software, bem como os conceitos bsicos existentes, explorando o
conceito de Processo e dos modelos de ciclo de vida, que so
elementos bsicos para entender a rea.
Na Unidade II faremos uma breve apresentao dos principais
fluxos da Engenharia de Software, que so chaves para o
desenvolvimento de um projeto e que sero abordados com mais
profundidade em outras disciplinas do curso.
Por fim, na Unidade III apresentamos um Processo de
Software, baseado nos princpios geis, exemplificando seu uso
para controle de um projeto envolvendo tarefas simples.

APRESENTAO







INTRODUO ENGENHARIA DE SOFTWARE

UNIDADE I ................................................................................................... 9
CONCEITOS BSICOS............................................................................. 9
1. O nicio................................................................................................... 9
1.1. Ser que a crise acabou? .............................................................. 12
1.2. O que Engenharia de Software? ................................................ 14
1.3. Problemas no desenvolvimento de software ................................ 17
1.4. Software: Mitos e Realidade ........................................................ 21
1.4.1. Mitos de Gerenciamento ...................................................... 22
1.4.2. Mitos do Cliente................................................................... 23
1.5. Mitos do Profissional ................................................................... 24
1.6. Exerccios..................................................................................... 25
2. Processos de Software.......................................................................... 26
2.1. Modelos de Ciclo de Vida............................................................ 28
2.1.1. Codifica-Remenda................................................................ 29
2.1.2. Cascata ................................................................................. 30
2.1.3. Espiral .................................................................................. 32
2.1.4. Incremental........................................................................... 33
2.1.5. Entrega Evolutiva................................................................. 37
2.1.6. Outros Modelos de Ciclo de Vida........................................ 38
2.2. Exerccios..................................................................................... 39
UNIDADE II ................................................................................................ 43
AS PRINCIPAIS DISCIPLINAS DA ENG. DE SOFTWARE ............. 43
3. Requisitos............................................................................................. 46
3.1. O Processo Praxis......................................................................... 46
3.2. O Fluxo de Requisitos.................................................................. 49
3.3. Exerccios..................................................................................... 55
4. Anlise.................................................................................................. 56
4.1. Exerccios..................................................................................... 59
5. Desenho................................................................................................ 60
5.1. Exerccios..................................................................................... 65
6. Implementao ..................................................................................... 66
6.1. Exerccios..................................................................................... 71
7. Testes.................................................................................................... 72
7.1. Exerccios..................................................................................... 75
8. Gesto de Projetos................................................................................ 76
8.1. Exerccios..................................................................................... 77
UNIDADE III ............................................................................................... 80
9. Um Exemplo de um Processo de Software.......................................... 82
SUMRIO GERAL

9.1. Os Papis...................................................................................... 84
9.2. As Cerimnias.............................................................................. 85
9.2.1. A Reunio Inicial ................................................................. 85
9.2.2. A Reunio de Planejamento................................................. 89
9.2.3. A Reunio Diria.................................................................. 97
9.2.4. Acompanhamento do Projeto............................................... 97
9.2.5. Apresentao do Sprint ........................................................ 98
9.2.6. Retrospectiva........................................................................ 99
9.3. Finalizao ................................................................................... 99
9.4. Exerccios................................................................................... 100
10. Aplicando o SCRUM..................................................................... 102
10.1. O Exemplo ............................................................................. 102
10.2. Discusso sobre o uso do Scrum............................................ 106
10.3. Exerccios............................................................................... 107








UNIDADE I
CONCEITOS BSICOS

RESUMO

Nesta unidade apresentamos os conceitos bsicos da
Engenharia de Software, definindo os pontos bsicos para o seu
entendimento.
No Capitulo 1 apresentamos o evento que deu origem a rea,
conhecido como a Crise do Software, discutindo se ela realmente
foi superada. Fazemos ainda uma definio precisa sobre o conceito
de Processo, que fundamental para a Engenharia de Software. Por
fim, apresentamos os mitos do software, que diferentemente dos
mitos tradicionais, trazem desinformao e geram problemas, ao
invs de serem histrias interessantes e cativantes.
No Captulo 2 apresentamos o conceito de ciclo de vida do
software, juntamente com a apresentao dos principais modelos de
ciclo de vida existentes, ressaltando aqueles que so mais utilizados
atualmente.









INTRODUO ENGENHARIA DE SOFTWARE

UNIDADE I ................................................................................................... 9
CONCEITOS BSICOS............................................................................. 9
1. O nicio................................................................................................... 9
1.1. Ser que a crise acabou? .............................................................. 12
1.2. O que Engenharia de Software? ................................................ 14
1.3. Problemas no desenvolvimento de software ................................ 17
1.4. Software: Mitos e Realidade ........................................................ 21
1.4.1. Mitos de Gerenciamento ...................................................... 22
1.4.2. Mitos do Cliente................................................................... 23
1.5. Mitos do Profissional ................................................................... 24
1.6. Exerccios..................................................................................... 25
2. Processos de Software.......................................................................... 26
2.1. Modelos de Ciclo de Vida............................................................ 28
2.1.1. Codifica-Remenda................................................................ 29
2.1.2. Cascata ................................................................................. 30
2.1.3. Espiral .................................................................................. 32
2.1.4. Incremental........................................................................... 33
2.1.5. Entrega Evolutiva................................................................. 37
2.1.6. Outros Modelos de Ciclo de Vida........................................ 38
2.2. Exerccios..................................................................................... 39


SUMRIO DA UNIDADE

UNIDADE I
CONCEITOS BSICOS
1. O Incio
A partir de 1961 o mundo presenciou o surgimento de novos
computadores, mais modernos e com mais poder computacional. A
partir dessa data o software ganhou notoriedade e, por conta disso,
uma srie de problemas relacionados ao amadorismo utilizado
para sua construo ficou evidente. Esses fatores originaram a Crise
do Software, em meados de 1968. O termo expressava as
dificuldades do desenvolvimento de software frente ao rpido
crescimento da demanda existente, da complexidade dos problemas
a serem resolvidos e da inexistncia de tcnicas estabelecidas para
o desenvolvimento de sistemas que funcionassem adequadamente
ou pudessem ser validados.

Figura 1: Fotos da NATO Software Engineering Conference.

Em 1968 aconteceu a NATO Software Engineering
Conference, um evento criado com o objetivo de discutir alternativas
para contornar a Crise do Software. Essa conferncia marcou assim
o incio dessa nova rea na computao. A Figura 1 mostra registros
dessa conferncia, que teve como um dos participantes o ilustre
professor de Matemtica, da Universidade Eindhoven de Tecnologia,
A Crise do Software
surgiu devido ao
amadorismo existente
na conduo do
processo de
desenvolver software.
Em 1968 surgiu a
Engenharia de
Software.
10
Edsger Dijkstra. Em 1972 Dijkstra recebeu o Prmio Turing (Turing
Award), que dado anualmente pela Association for Computing
Machinery (ACM), para uma pessoa selecionada por contribuies
de natureza tcnica feitas para a comunidade de computao. Seu
discurso para recebimento do prmio, intitulado O Pobre
Programador (The Humble Programmer) tornou-se um clssico da
Engenharia de Software. Um trecho desse discurso, traduzido para o
portugus e que resume a crise, exibido a seguir:
A maior causa da crise do software que as
mquinas tornaram-se vrias ordens de magnitude
mais poderosas! Para esclarecer melhor: quando no
havia mquinas, a programao no era um problema;
quando tnhamos poucos computadores, a
programao tornou-se um problema razovel, e
agora, que ns temos computadores gigantes, a
programao tornou-se um problema igualmente
grande..
Mas o que realmente seria a Crise do Software? Podemos
resumir a crise imaturidade no desenvolvimento de software,
causando diversos problemas, como por exemplo:
Projetos estourando o oramento.
Projetos estourando o prazo.
Software de baixa qualidade.
Software muitas vezes no atendendo os requisitos.
Projetos no gerenciveis e cdigo difcil de manter.
Dijkstra um
personagem ilustre da
computao, com
diversas contribuies
em diversas reas.
11

Figura 2: Exemplo de um quadro da situao na poca da crise do
software.

A Figura 2 exibe um quadro da situao relacionada ao
desenvolvimento de software poca da crise. Nesse perodo,
apenas 4% dos projetos eram finalizados e o produto gerado era
utilizado tal qual foi entregue; 29% dos produtos no eram
entregues, embora tenham sido pagos; 45% eram entregues, porm,
o produto resultante era impossvel de ser utilizado, normalmente,
por conter uma quantidade de incorrees que impediam sua
utilizao e 22% eram modificados, em muitos casos extremamente
modificados, para que pudessem ser utilizados.
Mesmo com a evoluo dos computadores, das tcnicas e
ferramentas nos ltimos anos, a produo de software confivel,
correto e entregue dentro dos prazos e custos estipulados ainda
4% - Usado como
foi entregue
45% - Impossvel de ser usado
29% - Pago e nunca entregue
22% - Modificado e
refeito para ser
utilizado
12
muito difcil. Dados do STANDISH GROUP, de 2004, usando como
base mais de 8000 projetos mostrou que apenas 29% dos projetos
foram entregues respeitando os prazos e os custos e com todas as
funcionalidades especificadas. Aproximadamente 18% dos projetos
foram cancelados antes de estarem completos e 53% foram
entregues, porm com prazos maiores, custos maiores ou com
menos funcionalidades do que especificado no incio do projeto.
Dentre os projetos que no foram finalizados de acordo com os
prazos e custos especificados, a mdia de atrasos foi de 222%, e a
mdia de custo foi de 189% a mais do que o previsto. Considerando
todos os projetos que foram entregues, alm do prazo e com custo
maior, na mdia, apenas 61% das funcionalidades originais foram
includas. Mesmo os projetos cuja entrega feita respeitando os
limites de prazo e custo, possuem qualidade suspeita, uma vez que
provavelmente foram feitos com muita presso sobre os
desenvolvedores, o que pode quadruplicar o nmero de erros de
software, segundo a mesma pesquisa.
1.1. Ser que a crise acabou?

Uma pergunta que devemos nos fazer atualmente : ser que
a crise acabou? Para respond-la necessrio fazer uma srie de
anlises.
Ainda hoje diversos
projetos de
desenvolvimento de
software fracassam.
13

Figura 3: Dificuldades durante o desenvolvimento de software.

A Figura 3 apresenta uma ilustrao muito conhecida na rea
de Engenharia de Software. Ela apresenta um grande problema,
relacionado falta de entendimento entre os grupos que fazem parte
de um projeto. O quadro inicial da figura apresenta uma ilustrao
tentando expressar como o cliente explicou o que necessitava para a
equipe de desenvolvimento. O quadro seguinte exibe como o lder
do projeto entendeu. Podemos notar que existe uma diferena
significativa entre as figuras. Isso no deveria acontecer, ou deveria
haver o mnimo possvel de diferenas. Desse ponto adiante existe
uma srie de entendimentos diferentes, algumas vezes causados
por falhas na comunicao, outros por comodidade, uma vez que
certos entendimentos favorecem alguns grupos. O resultado de tudo
isso que o produto resultante tende a ser algo totalmente
discrepante do que foi solicitado e ainda mais diferente do que
realmente era necessitado. Observe que, o ltimo quadro na figura
apresenta o que o cliente realmente desejava, que bastante
diferente do que ele relatou que necessitava. Mais adiante, quando
Um grande problema a
ser superado a falha
na comunicao entre
as equipes.
14
falarmos de requisitos e na prxima disciplina relacionada
Engenharia de Software, que trata exclusivamente de requisitos,
vamos entender isso com muito mais clareza.
Embora problemas durante o desenvolvimento de software
aconteam, e com certa freqncia, os processos, mtodos e
ferramentas existentes auxiliam muito o desenvolvimento. Uma vez
aplicados por pessoas com os conhecimentos adequados, podemos
ter certeza do sucesso em um projeto. Por conta disso que existem
diversos projetos grandes com sucesso absoluto. Para isso,
necessrio aplicar, corretamente, a Engenharia de Software! Ou
seja, respondendo questo inicialmente formulada nesta seo: a
crise acabou, mas apenas para aqueles que utilizam a Engenharia
de Software como base para a construo de produtos de software.
1.2. O que Engenharia de Software?

J comentamos sobre as origens da Engenharia de Software
mas at agora no fizemos uma definio precisa do que seja
exatamente isso. Nesta seo faremos isso. Mas antes da definio,
vamos fazer uma analogia muito interessante: voc sabe como
funciona o processo de fabricao de um carro?


Unidades Integrao
Integrao Produto
Concludo
Requisitos
Projeto e
Simulaes
Figura 4: Passos para desenvolvimento de um carro.
Assim como na
construo civil, muitas
empresas estouram
custos e prazos, mesmo
tendo mtodos e
tcnicas bem
estabelecidas. No
desenvolvimento de
software a situao a
mesma: aqueles que
utilizam os princpios
corretamente tm
grandes chances de
sucesso.
15

A Figura 4 apresenta os passos para desenvolvimento de um
carro. Sua construo inicia a partir do momento que tem-se a idia
de iniciar essa tarefa. A partir disso, iniciado o levantamento das
caractersticas, necessidades e desejos relacionados ao produto.
Tudo isso ir compor a especificao de requisitos do carro. So
exemplos desses requisitos porta-malas com capacidade de 500l,
motor 1.6, cmbio automtico, etc. Com a identificao dos
requisitos possvel iniciar a montagem de um prottipo, para se
avaliar diversos pontos que necessitam de esclarecimento antes da
construo efetiva do carro. Essa prototipao pode ser feita via
ferramentas de simulao, como as famosas ferramentas CAD
existentes ou a partir da criao de verses em miniatura do produto
(Figura 4, Projeto e Simulaes). O modelo criado, seja qual for,
normalmente utilizado para responder diversas questes, para em
seguida dar-se incio ao desenvolvimento das partes que iro
compor o automvel. Essas partes so chamadas de unidades,
como por exemplo, a barra de direo, a porta, o motor, as rodas,
etc (Figura 4, Unidades). Cada componente do carro possui
especificaes e precisa ser verificado com relao a isso. Por
exemplo, a barra de direo deve ser retilnea, com 1,80m de
extenso e deve suportar at 500 kg em seu ponto central. A
verificao consiste em analisar se isso realmente foi atendimento
pelo processo de fabricao do componente. Se o item no passar
nessa verificao, no podemos continuar com a construo do
produto, pois certamente haver mais problemas quando utilizarmos
o componente com problemas. Caso os componentes sejam
aprovados na verificao, podemos iniciar a combinao desses
componentes, integrando-os, para em seguida verificar se eles
continuam atendendo s especificaes (Figura 4, Integrao).
Como exemplo, imagine que a barra de direo do carro foi
integrada s rodas. Ela deveria sustentar os 500 kg em seu ponto
central. Embora isso j tenha sido verificado aps a fabricao do
16
item, uma nova verificao necessria aps sua integrao com
demais elementos, uma vez que agora o ponto de falha pode no
ser a barra de direo em si, mas os pontos de conexo entre a
barra e as rodas. Caso os componentes agrupados continuem
funcionando conforme o esperado, poderemos continuar o
agrupamento at que tenhamos o produto completo. Uma vez tendo
terminado o produto, teremos que submet-lo a uma srie de
avaliaes para verificar o seu nvel de qualidade. No caso de um
carro so necessrios testes de desempenho, consumo, segurana,
etc. Aps essa verificao poderemos afirmar que o produto foi
concludo com sucesso.
Mas por que conversar sobre carros se o objetivo desta seo
apresentar o conceito de Engenharia de Software? Justamente por
que o processo de fabricao de um carro tem tudo haver com a
Engenharia de Software. De modo geral, podemos dizer que
Engenharia de Software poderia ser resumida utilizao de
princpios de engenharia para o desenvolvimento de software, ou
seja, levantar os requisitos associados, construir modelos para
representar a soluo a ser desenvolvida, implementar as diversas
unidades que iro compor o produto, verificando se tais unidades
atendem aos requisitos identificados, realizar a integrao entre as
unidades, tambm verificando seu funcionamento, at que tenhamos
o produto por completo, que deve passar por uma srie de
verificaes (teste funcionais, desempenho e estresse, usabilidade,
etc.) para que possamos concluir o desenvolvimento. Em resumo e
utilizando termos mais formais, podemos dizer que a Engenharia de
Software a aplicao de uma abordagem sistemtica,
disciplinada e quantificvel para o desenvolvimento de
software.
Na literatura, podem-se encontrar mais definies para
Engenharia de Software, dentre eles destacamos:
"O estabelecimento e uso de slidos princpios de engenharia para
que se possa obter economicamente um software que seja confivel e
A construo de um
carro e a construo de
um software so
projetos similares, mas
que exigem diferentes
habilidades na sua
conduo e execuo.
17
que funcione eficientemente em mquinas reais.", NAUR PETER,
1969.

A aplicao prtica do conhecimento cientfico para o projeto e a
construo de programas computacionais e a documentao
necessria sua operao e manuteno., BARRY BOEHM,
1976.

Conjunto de mtodos, tcnicas e ferramentas necessrias
produo de software de qualidade para todas as etapas do ciclo de
vida do produto., SACHA KRAKOWIAK, 1985.

Num ponto de vista mais formal, a Engenharia de Software
pode ser definida como sendo a aplicao da cincia e da
matemtica atravs das quais os equipamentos computacionais so
colocados disposio do homem por meio de programas,
procedimentos e documentao associada. De modo mais objetivo,
pode-se dizer que a Engenharia de Software busca prover a
tecnologia necessria para produzir software de alta qualidade a um
baixo custo. Os dois fatores motivadores so essencialmente a
qualidade e o custo. A qualidade de um produto de software um
parmetro cuja quantificao no trivial, apesar dos esforos
desenvolvidos nesta direo. Por outro lado, o fator custo pode ser
facilmente quantificado desde que os procedimentos de
contabilidade tenham sido corretamente efetuados.
Um grande problema facilmente percebido hoje justamente
o fato de boa parte das organizaes no encararem o
desenvolvimento de software como um projeto de verdade,
aplicando as tcnicas, mtodos e ferramentas necessrias. Por
conta disso, boa parte desses projetos fracassa. Na prxima seo
vamos discutir alguns dos aspectos que fazem isso acontecer.
1.3. Problemas no desenvolvimento de software

Embora a Engenharia de Software seja uma rea consolidada
e existam vrias empresas que a utilizam com muito sucesso em
projetos de desenvolvimento de software, isso no verdade na
18
maioria dos casos. A crise continua em muitos locais, no mais por
ausncia de mtodos, tcnicas e ferramentas, mas pela falta do seu
uso!

Figura 5: Trip da Engenharia de Software.

A Figura 5 apresenta o trip no qual a Engenharia de
Software baseada: processos, pessoas e tecnologia. No adianta
termos os melhores profissionais do mundo se no possumos boas
tecnologias para uso ou se no possumos um processo que guie o
desenvolvimento de software. Da mesma forma, no adianta possuir
as tecnologias mais avanadas se as pessoas no conseguem
utiliz-las. Alm disso, mesmo que parea inconcebvel para alguns,
de nada adianta termos a melhor tecnologia e as melhores pessoas
se no existe um processo que guie as atividades dessas pessoas
utilizando tais tecnologias. Existem grande chances de termos
problemas relacionados falta de controle ou desorganizao, caso
no tenhamos um processo que discipline as tarefas das pessoas.

Figura 6: Componentes de um sistema.

preciso um equilbrio
entre Pessoas,
Processos e
Tecnologias para o
sucesso em um projeto
de desenvolvimento de
software.
19
Um conceito que muitas vezes causa confuso o de
sistema, que muito se confunde ao conceito de software. Pode-se
definir o software, numa forma clssica, como sendo: "um conjunto
de instrues que, quando executadas, produzem a funo e o
desempenho desejados, estruturas de dados que permitam que as
informaes relativas ao problema a resolver sejam manipuladas
adequadamente e a documentao necessria para um melhor
entendimento da sua operao e uso".
Entretanto, no contexto da Engenharia de Software, o
software deve ser visto como um produto a ser "vendido".
importante dar esta nfase, diferenciando os "programas" que so
concebidos num contexto mais restrito, onde o usurio ou "cliente"
o prprio autor. No caso destes programas, a documentao
associada pequena ou (na maior parte das vezes) inexistente e a
preocupao com a existncia de erros de execuo no um fator
maior, considerando que o principal usurio o prprio autor do
programa, este no ter dificuldades, em princpio, na deteco e
correo de um eventual "bug". Alm do aspecto da correo, outras
boas caractersticas no so tambm objeto de preocupao como a
portabilidade, a flexibilidade e a possibilidade de reutilizao.
Um produto de software (ou software, como vamos
chamar ao longo da disciplina), por outro lado, sistematicamente
destinado ao uso por pessoas diferentes dos seus programadores.
Os eventuais usurios podem ter formaes e experincias
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 explorados de forma
eficiente. Ainda, os produtos de software devem passar
normalmente por uma exaustiva bateria de testes, dado que os
usurios no estaro interessados (e nem tero capacidade) de
detectar e corrigir os eventuais erros de execuo.
O termo bug est
associado ao conceito
de falha. Bug signifca
inseto em Ingls. Diz-se
que o termo foi criado
por Thomas Edison
quando um inseto
causou problemas de
leitura em seu fongrafo
em 1878, mas pode ser
que o termo seja mais
antigo. A inveno do
termo atribuda
erroneamente a Grace
Hopper, que publicou
em 1945 a causa do
mau funcionamento no
Mark II (um dos
primeiros
computadores) seria um
inseto preso nos
contatos de um Rel.
20
Resumindo, um programa desenvolvido para resolver um
dado problema e um produto de software destinado resoluo do
mesmo problema so duas coisas totalmente diferentes. bvio que
o esforo e o conseqente custo associado ao desenvolvimento de
um produto sero muito superiores.
Um sistema bem mais que o software. Na verdade, o
sistema o conjunto de elementos, coordenados entre si e que
funcionam como uma estrutura organizada. Embora o software seja
uma parte importante de um sistema, ele no a nica. Se no
existir o hardware para execuo do software, de nada servir. Da
mesma forma, necessrio existir bases de dados, uma vez que
praticamente todos os sistemas com algum tipo de utilidade devem
armazenar dados. Atualmente, com o advento da Internet,
dificilmente um sistema seja til se no tiver certos mecanismos de
comunicao associados. Tudo isso junto, forma o sistema. Por
diversas vezes tendemos a utilizar software e sistema como algo
similar, mas importante ressaltarmos suas diferenas, de forma a
deixar claro o que representa cada um desses termos.
Os produtos de software desenvolvidos utilizando a
Engenharia de Software sempre esto envolvidos em algum
processo de negcio, seja ele simples ou complexo. Assim,
fundamental entender esse processo de negcio para que seja
possvel informatiz-lo. Embora isso seja bvio, em muitas ocasies
isso simplesmente ignorado. O desenvolvimento de software
muitas vezes acontece sem sabermos o que deve ser feito.
Logicamente isso tem grande chance de resultar em fracasso.
importante ressaltar que isso inconcebvel em qualquer
rea, mas parece que muitos acreditam que quando tratamos de
software algo diferente. Imagine adentrar em uma construtora de
respeito e perguntar: quanto custa construir uma casa? Se a
empresa for sria, certamente no vai dar nenhuma estimativa de
custo nem de prazo, uma vez que nada foi dito sobre o projeto. Uma
casa pode ser feita gastando-se R$1.000,00 ou R$1.000.000,00.
21
Tudo depende dos requisitos relacionados casa. Com o software
exatamente o mesmo. Se no soubermos quais so os requisitos
simplesmente impossvel fazer qualquer estimativa de tempo e
custo. Qualquer ao nesse sentido irresponsabilidade ou extrema
ignorncia!
Em resumo, os sistemas informatizados normalmente no
fazem o que deveriam fazer por que os problemas tm que ser
minuciosamente definidos para que possam ser resolvidos. Se no
entendermos bem sobre o domnio do problema, certamente no
desenvolveremos uma boa soluo. fundamental levantarmos os
requisitos de um software antes de procedermos com sua
construo. O custo para levantamento desses requisitos um fator
a ser considerado, mas no fazer tal levantamento provavelmente
seja bem mais caro! Alm disso, importante que os usurios do
produto participem desse levantamento, caso contrrio, os dados
obtidos no levantamento no devero expressar aquilo que
realmente importante para o processo de negcio.
1.4. Software: Mitos e Realidade

Muitas causas de problemas relacionados ao
desenvolvimento de software so provenientes de mitos que
surgiram durante a histria inicial dessa atividade, conforme descrito
por ROGER PRESSMAN. Diferente dos antigos mitos, que so
interessantes histrias e freqentemente fornecem lies humanas
merecedoras de ateno, os mitos de software propagam
desinformao e confuso. Esses mitos tinham certos atributos que
os tornavam parecidos com afirmaes razoveis, tendo aspecto
intuitivo e, muitas das vezes, eram divulgados por profissionais
experientes e que deveriam entender do assunto. Atualmente, boa
parte dos profissionais reconhece os mitos por aquilo que so:
afirmaes enganosas e que j causaram problemas. No entanto,
22
cabe a todos ns conhec-los, para tentar evit-los em locais que
isso ainda esteja acontecendo.
1.4.1. Mitos de Gerenciamento

Mito 1. "Se a equipe dispe de um manual repleto de padres
e procedimentos de desenvolvimento de software, ento a equipe
ser capaz de conduzir bem o desenvolvimento."
Realidade 1. Isso no o suficiente! preciso que a equipe
aplique efetivamente os conhecimentos apresentados no manual.
necessrio que o manual reflita a moderna prtica de
desenvolvimento de software e que este seja exaustivo com relao
a todos os problemas de desenvolvimento que podero aparecer no
percurso.
Mito 2. "A equipe tem ferramentas de desenvolvimento de
software de ltima gerao, uma vez que eles dispem de
computadores modernos."
Realidade 2. Ter sua disposio o ltimo modelo de
computador pode ser bastante confortvel para o desenvolvedor do
software, mas no oferece nenhuma garantia quanto qualidade do
produto desenvolvido. Mais importante do que ter um hardware de
ltima gerao ter ferramentas para a automao do
desenvolvimento de software e sab-las utilizar adequadamente.
Mito 3. "Se o desenvolvimento do software estiver atrasado,
aumentando a equipe poderemos reduzir o tempo de
desenvolvimento."
Realidade 3. Acrescentar pessoas em um projeto atrasado
provavelmente vai atras-lo ainda mais. De fato, a introduo de
novos profissionais numa equipe em fase de conduo de um
projeto vai requerer uma etapa de treinamento dos novos elementos
da equipe; para isto, sero utilizados elementos que esto
envolvidos diretamente no desenvolvimento, o que vai,
conseqentemente, implicar em maiores atrasos no cronograma.
23
1.4.2. Mitos do Cliente

Mito 4. "Uma descrio breve e geral dos requisitos do
software o suficiente para iniciar o seu projeto. Maiores detalhes
podem ser definidos posteriormente."
Realidade 4. Este um dos problemas que podem conduzir
um projeto ao fracasso, o cliente deve procurar definir o mais
precisamente possvel todos os requisitos importantes para o
software: funes, desempenho, interfaces, restries de projeto e
critrios de validao so alguns dos pontos determinantes do
sucesso de um projeto. O deixar pra depois pode simplesmente
no acontecer, a no ser em casos previstos pelos processos geis
em que os clientes esto sempre presente e dentro da organizao
desenvolvedora. No entanto, sabido que essa prtica uma das
mais difceis de serem seguidas...
Mito 5. "Os requisitos de projeto mudam continuamente
durante o seu desenvolvimento, mas isto no representa um
problema, uma vez que o software flexvel e poder suportar
facilmente as alteraes."
Realidade 5. verdade que o software flexvel (pelo menos
mais flexvel do que a maioria dos produtos manufaturados).
Entretanto, no existe software, por mais flexvel que suporte
alteraes de requisitos significativas sem um adicional em relao
ao custo de desenvolvimento. O fator de multiplicao nos custos de
desenvolvimento do software devido a alteraes nos requisitos
cresce em funo do estgio de evoluo do projeto, como mostra a
Figura 7.



24
\
1 x
1.5 ~ 6 x
60 ~ 100 x
DEFINIO DESENVOLVIMENTO MANUTENO
C
U
S
T
O

Figura 7: Influncia das alteraes de requisitos no custo de um
sistema.

1.5. Mitos do Profissional

Mito 6. "Aps a finalizao do programa e a sua implantao,
o trabalho est terminado."
Realidade 6. O que ocorre na realidade completamente
diferente disto. Segundo dados obtidos a partir de experincias
anteriores, ilustrados no livro de Roger Pressman, 50 a 70% do
esforo de desenvolvimento de um software empregado aps a
sua entrega ao cliente (manuteno).
Mito 7. "Enquanto o programa no entrar em funcionamento,
impossvel avaliar a sua qualidade."
Realidade 7. Na realidade, a preocupao com a garantia do
da qualidade do software deve fazer parte de todas as etapas do
desenvolvimento. O teste, por exemplo, pode iniciar antes do
produto atingir um estado funcional, a partir do planejamento dos
casos de teste.
Mito 8. "O produto a ser entregue no final do projeto o
programa funcionando."
25
Realidade 8. O programa em funcionamento um das
componentes do software. Alm do software em si, um bom projeto
deve ser caracterizado pela produo de um conjunto importante de
documentos. Um produto de software sem um manual de operao
pode ser to ruim quanto um software que no funciona!
1.6. Exerccios

1. Qual foi a principal causa do surgimento da Engenharia de
software?
2. Quais eram os problemas associados Crise do
Software?
3. A crise do software realmente acabou? Comente sobre
isso.
4. Faca uma comparao entre a Engenharia de Software e
o desenvolvimento de um carro.
5. Defina Engenharia de Software.
6. Qual o trip em que a Engenharia de Software est
baseada?
7. O que um sistema? Quais seus principais componentes?
8. possvel fazer a estimativa de custo e prazo para
desenvolvimento de um software com apenas alguns
poucos minutos de conversa? Comente sobre isso
relacionando sua resposta a outras reas.
9. O que so os mitos do Software?
10. Cite alguns mitos relacionados ao gerenciamento,
comentando a realidade relacionada aos mitos.
11. Cite alguns mitos relacionados aos clientes, comentando a
realidade relacionada aos mitos.
12. Cite alguns mitos relacionados aos profissionais do
desenvolvimento de software, comentando a realidade
relacionada aos mitos.
26
UNIDADE I
CONCEITOS BSICOS
2. Processos de Software

Conforme comentado no captulo anterior, a Engenharia de
Software nada mais que o tratamento do software como um
produto, empregando dentro do processo de desenvolvimento todos
os princpios da engenharia. Como todo produto, o software tambm
possui um ciclo de vida, que pode ser definido como o conjunto de
todas as etapas relacionadas sua existncia, desde a sua
concepo, at o seu desaparecimento. Isso inclui uma srie de
etapas, dentre elas as destacadas a seguir:
a concepo, onde o produto idealizado, a partir da
percepo de uma necessidade;
o desenvolvimento, a partir da identificao dos requisitos e
sua transformao em itens a serem entregues ao cliente;
a operao, quando o produto instalado para ser utilizado
em algum processo de negcio, sujeito a manuteno,
sempre que necessrio;
a retirada, quando o produto tem sua vida til finalizada.
No ciclo de vida de um software, a codificao, que
representa a escrita do programa utilizando alguma linguagem de
programao, apenas uma parte do ciclo de vida, embora muitos
profissionais de informtica acreditem, erroneamente, que essa seja
a nica tarefa relacionada ao desenvolvimento de software.
E j que estamos em um captulo denominado Processo de
Software, qual a relao com Ciclo de Vida? O Processo de
Software um guia de como um produto de software deve ser
construdo, do incio ao fim. A ligao est no fato que esse guia
depende do modelo de ciclo de vida utilizado. Existem vrios
27
modelos e dependendo dele, as atividades a serem executadas
podem variar. Essa a ligao.
Necessitamos ainda definir o conceito de Processos de
Software com maior exatido. Um processo um conjunto de
passos parcialmente ordenados, constitudos por atividades,
mtodos, prticas e transformaes, utilizados para se atingir uma
meta. Uma meta est associada a resultados, que so os produtos
resultantes da execuo do processo.
importante percebermos outra diferena que muitas vezes
imperceptvel para muitos profissionais de informtica: enquanto o
processo um guia para se construir um produto, um projeto o uso
de um processo para desenvolvimento de um produto especfico.
Isso se assemelha muito ao conceito de classe e objeto. Enquanto
que classe uma estrutura que abstrai um conjunto de objetos com
caractersticas similares, um objeto uma instncia da classe, com
valores especficos para cada uma dessas caractersticas. Dessa
forma, o processo est para classe assim como o projeto est para
um objeto. Em resumo, um projeto a instanciao de um processo
para a construo de um produto.
De acordo com Wilson de Pdua, um processo deve ter uma
documentao que o descreve, apresentando detalhes sobre o que
feito (produto), quando (passos), por quem (agentes), o que usa
como entrada (insumo) e o que produzido (resultado). Essa
documentao pode ser simples e informal, como o caso dos
Processos geis, que veremos mais adiante, ou completamente
detalhada, como o caso dos processos baseados no Processo
Unificado.
Existem processos que abrangem todo o ciclo de vida do
software, assim como processos especficos para partes do
desenvolvimento, como, por exemplo, processos para testes,
processos para manuteno, etc., que so considerados
subprocessos.

28
O ponto inicial para seleo de um processo, e posterior
iniciao de um projeto, entender qual modelo de ciclo de vida ele
utiliza. Um modelo de ciclo de vida pode ser apropriado para um
projeto mas no ser apropriado para outro. necessrio entender
bem os conceitos relacionados para que as escolhas feitas sejam
baseadas em conhecimento e no no acaso. Na prxima seo
iremos detalhar os modelos de ciclo de vida existentes, que muitas
vezes so tratados como paradigmas de engenharia de software.
Neste trabalho vamos utilizar o termo modelo de ciclo de vida ao
invs de paradigma, por acharmos que ele mais apropriado.
2.1. Modelos de Ciclo de Vida

Conforme j comentado, ciclo de vida pode ser resumido
como sendo todas as atividades relacionadas a um software, desde
a concepo de suas idias at a descontinuidade do produto.
Existem diversos modelos de ciclo de vida, com caractersticas
diferentes. Nesta seo iremos apresentar os principais modelos de
ciclo de vida.
Para detalhamento dos modelos de ciclo de vida,
necessitaremos entender melhor cada um dos subprocessos mais
importantes ligados s tarefas de desenvolvimento. Esses
subprocessos so organizados de acordo com um tema e so
chamados tambm de fluxos ou disciplinas. A seguir apresentamos
uma breve descrio desses subprocessos, que sero um pouco
mais detalhados nos captulos posteriores:
Requisitos: obteno do enunciado, completo, claro e preciso
dos desejos, necessidades, expectativas e restries dos
clientes em relao ao produto a ser desenvolvido.
Anlise: modelagem dos conceitos relevantes do domnio do
problema, com o intuito de verificar a qualidade dos requisitos
obtidos e detalhar tais requisitos em um nvel adequado aos
desenvolvedores.
O termo modelo de ciclo
de vida utilizado para
descrever um grupo de
atividades relacionado
ao desenvolvimento de
software e a forma
como elas se
relacionam. Para cada
modelo de ciclo de vida
existe um
relacionamento
diferente entre as
atividades,
determinando formas
diferente de se conduzir
o processo de
construo do produto.
29
Desenho (ou projeto): definio de uma estrutura
implementvel para um produto, que atenda aos requisitos
especificados.
Implementao: codificao das partes que compe o
software, definidas no desenho, utilizando as tecnologias
selecionadas.
Teste: verificao dinmica das partes que constituem o
software, utilizando um conjunto finito de casos de teste,
selecionados dentro de um domnio potencialmente infinito,
contra seu comportamento esperado.

A literatura cita vrios tipos de modelos de ciclo de vida de
software. No consideramos que alguns desses modelos devam
receber este status. No entanto, iremos comentar sobre eles ao final
da Seo. So exemplos o modelo de prototipao e modelo de
desenvolvimento rpido. Esses modelos so, em nossa viso,
apenas o desenvolvimento de software baseado em certas tcnicas
e ferramentas. Embora alguns autores renomados os apresentem
como modelos de ciclo de vida, o autor os considera como
abordagens para aplicao do ciclo de vida.
2.1.1. Codifica-Remenda

O modelo de ciclo de vida mais utilizado o modelo codifica-
remenda. Conforme exibido na Figura 8, partindo de uma
especificao incompleta, ou mesmo ausente, inicia-se a codificao
do software, que por sua vez tende a gerar algo. Esse algo
gerado, na grande maioria das vezes no o que o cliente deseja,
mas vai sendo alterado e consertado at que o produto atinja um
estgio que permita seu uso. Nenhum processo seguido nessa
iterao.
30


A grande utilizao desse modelo se d em virtude de boa
parte dos profissionais responsveis pelo desenvolvimento de
software no terem qualquer conhecimento sobre a Engenharia de
Software. possvel que o uso desse modelo de ciclo de vida gere
resultados aceitveis para produtos pequenos e com equipes
formadas por poucas pessoas, normalmente por um nico
desenvolvedor, mas certamente ele s gerar problemas em
qualquer projeto envolvendo produtos que requeiram equipes
maiores.
O aspecto positivo desse modelo que no exige nenhum
conhecimento tcnico ou gerencial. Basta iniciar, sem muito preparo
sobre o tema a ser abordado, e trabalhar para gerar algo como
resultado. Por outro lado, um modelo de alto risco, praticamente
impossvel de se gerenciar, tornando-se impossvel estabelecer
qualquer estimativa de custo e prazo.
2.1.2. Cascata

O modelo em cascata, tambm conhecido como modelo
seqencial linear, sugere que os principais subprocessos
relacionados ao desenvolvimento de software sejam executadas em
seqncia, conforme apresentado na Figura 9.
Figura 8: O modelo de ciclo de vida codifica-remenda.
Esse modelo ainda o
mais comum, pela falta
de profissionais
habilitados para o
desenvolvimento de
software. De forma
similar, existem muito
mais obras sendo
tocadas por
profissionais sem
qualquer formao
tcnica, do que obras
tocadas por
engenheiros. O
resultado disso que
dificilmente uma obra
sem um engenheiro
possuir custo e prazo
conhecido!
31
Figura 9: O modelo de ciclo de vida em Cascata.

Esse modelo de ciclo de vida (ou paradigma) foi muito
utilizado no passado. No entanto, devido a falhas durante sua
execuo, ele vem sendo preterido por outros modelos. Dentre
essas falhas, destacam-se as relatadas por Pressman:
Projetos reais raramente seguem o fluxo seqencial,
conforme sugerido pelo modelo. Isso pode causar grandes
problemas quando temos mudanas em um projeto em
andamento.
Em geral, difcil para os clientes identificarem todos os
requisitos explicitamente. Esse modelo exige isso e tem
dificuldade em acomodar a incerteza natural que existem em
grande parte dos projetos.
O cliente precisa ter pacincia, uma vez que a primeira verso
executvel do produto somente estar disponvel no fim do
projeto. Erros grosseiros podem ser desastrosos e causar
perda de praticamente todo o trabalho. Esse talvez o maior
problema: a baixa visibilidade por parte do cliente.

Requi si tos
Anl i se
Desenho
Impl ementao
Testes
O modelo em cascata ,
em teoria, uma
maravilha. Na prtica
rgido e burocrtico,
tendo sido considervel
invivel pelas
organizaes que o
utilizam!
32
2.1.3. Espiral

Um modelo bem diferente do apresentado anteriormente
(cascata) o modelo em Espiral. Esse modelo foi proposto
originalmente por Barry Boehm. A idia bsica desenvolver um
produto a partir de pequenas verses incrementais, que podem
iniciar com um modelo em papel e evoluir at verses do sistema
completamente funcionais.


Figura 10: O modelo de ciclo de vida em espiral.


Podemos fazer uma comparao com o modelo em cascata:
uma volta na espiral equivale execuo do modelo em cascata
para uma pequena parte do software. Durante essa volta na espiral,
deve ser realizado o levantamento de requisitos para a pequena
parte do software que desejamos abordar, a modelagem desses
requisitos (anlise), o projeto das partes que sero desenvolvidas
(desenho), a codificao dessas partes (implementao) e sua
verificao (teste). Quando isso acontece temos o incio de um novo
ciclo e tudo se repete, at que tenhamos todo o produto
desenvolvido.

Ativao Anlise
Desenvolvimento Operao
A idia bsica por trs
do modelo em espiral :
dividir para conquistar!
Ao invs de querer
resolver todos os
problemas de uma vez,
interessante resolver
parte dele e ento partir
para o restante.
33
importante ressaltar que as diversas voltas na espiral so
utilizadas para se construir as partes do produto, mas essas partes
intermedirias e ainda incompletas do produto no so entregues ao
cliente. Essa abordagem utilizada apenas para a reduo dos
riscos e para o enfoque maior naquilo que mais
importante/complexo/crtico no sistema. O prximo modelo de ciclo
de vida que apresentamos baseado nesse modelo, porm
apresenta uma leve e sutil diferena: a entrega das partes para o
cliente.
O fato de dividir um sistema para trat-lo por partes favorece
o entendimento e facilita a prpria vida dos clientes, que podem
emitir opinies e identificar requisitos com mais propriedade. Isso
facilita o uso desse tipo de modelo de ciclo de vida. No entanto,
como apenas uma parte do produto considerada, possvel que
uma deciso tomada seja incompatvel com uma nova parte sendo
desenvolvida. Isso acontece por que a tomada de decises feita
apenas com o conhecimento do produto que existe at o momento.
O ideal seria que todo o produto j fosse conhecido, o que nos
remete ao modelo em cascata novamente. Esse ponto justamente
o problema do modelo em espiral: sua dificuldade de gerir, para que
tenhamos estimativas em um projeto que sejam previsveis e
confiveis.
2.1.4. Incremental

O modelo incremental, tambm denominado de prototipagem
evolutiva, baseado no modelo em espiral. No entanto, a grande
diferena para o modelo anterior que as verses parciais do
produto so efetivamente entregues aos clientes, para que sejam
verificadas, validadas e utilizadas no ambiente operacional.
importante ressaltar essa diferena: o modelo incremental no
utilizado apenas para construir o produto por completo, mas uma
srie de verses provisrias, denominadas prottipos, que cobrem
34
cada vez mais requisitos e que so efetivamente entregues aos
clientes.

Figura 11: O modelo de ciclo de vida incremental (prototipagem
evolutiva).

No modelo incremental um projeto dividido em vrias
iteraes, que so as divises do produto que sero consideradas
durante a construo. Escolhe-se uma dessas iteraes para iniciar
o desenvolvimento, comeando pelo planejamento da iterao,
levantamento de requisitos, anlise, desenho, implementao, testes
e avaliao da iterao, geralmente realizada com a participao do
cliente, conforme apresentado na Figura 11. Essa verso do
software normalmente liberada para uso e, caso o produto no
tenha sido concludo, uma nova iterao planejada para prosseguir
com o desenvolvimento.
O modelo incremental sofre dos mesmos problemas do
modelo em espiral, no entanto, apresenta como grande vantagem o
fato dos requisitos serem definidos progressivamente, sua alta
flexibilidade e visibilidade para os clientes. No entanto, requer
gerncia sofisticada e uma arquitetura forte, para que o produto
inicialmente concebido no esbarre em problemas que impeam sua
Pl anejamento
da iterao
Requi si tos Anl ise
Desenho
Impl ementao Testes Avali ao da
iterao
Proj eto termi nado
Nova iterao
Embora os processos
geis prescrevam pouca
burocracia, eles
prescrevem alguma
burocracia. No segui-
las pode significar
anarquia total no
desenvolvimento.
Existem muitas
organizaes que dizem
seguir os preceitos
geis, apenas por que
no seguem nada, o
que um completo
absurdo e podem
manchar as
metodologias geis
35
continuidade a partir dos direcionamentos (decises arquiteturais)
inicialmente concebidos.

Processos de software famosos, como o XP e Scrum utilizam
esse modelo de ciclo de vida. Esses processos so conhecidos
como Processos (ou Mtodos ou Metodologias) geis, em virtude de
darem mais importncia ao software funcionando do que qualquer
outro artefato gerado durante o desenvolvimento.
Os Mtodos geis surgiram como uma resposta aos mtodos
mais estruturados, especialmente aos mtodos baseados no modelo
em cascata. Processos orientados a documentao para o
desenvolvimento de software, como o utilizado no modelo em
Cascata, so de certa forma fatores limitadores aos
desenvolvedores. Muitas organizaes no possuem recursos ou
inclinao para processos burocrticos para a produo de software,
baseados em intensa documentao. Por esta razo, muitas
organizaes acabam por no usar nenhum processo, o que pode
levar a efeitos desastrosos em termos de qualidade de software,
conforme descrito por Alistais Cockbun. Como alternativa a esse
cenrio, surgiram os mtodos geis, que, apesar de possurem
documentao e alguma burocracia, so mais flexveis, orientadas a
entregas e possuem uma maior iteratividade no processo de
desenvolvimento e codificao do produto.
A maioria dos mtodos geis no possui nada de novo em
relao aos processos tradicionais. O que os diferencia dos outros
mtodos so o enfoque e os valores. A idia dos mtodos geis o
enfoque nas pessoas e no em processos ou algoritmos. Alm
disso, existe a preocupao de gastar menos tempo com
documentao e mais com a implementao. Uma caracterstica dos
mtodos geis que eles so adaptativos ao invs de serem
preditivos. Com isso, eles se adaptam a novos fatores decorrentes
do desenvolvimento do projeto, ao invs de procurar analisar
previamente tudo o que pode acontecer no decorrer do
desenvolvimento.
36
O termo metodologias geis tornou-se popular em 2001
quando diversos especialistas em processos de desenvolvimento de
software representando as metodologias Extreme Programming
(XP), SCRUM, DSDM (Dynamic Systems Development
Methodology), Crystal e outros, estabeleceram princpios comuns
compartilhados por todos esses mtodos. O resultado foi a criao
da Aliana gil, e o estabelecimento do Manifesto gil (Agile
Manifesto). Os conceitos chaves do Manifesto gil so:
Indivduos e interaes ao invs de processos e ferramentas;
Software executvel ao invs de documentao;
Colaborao do cliente ao invs de negociao de contratos;
Respostas rpidas a mudanas ao invs de seguir planos.

O Manifesto gil no rejeita os processos e ferramentas, a
documentao, a negociao de contratos ou o planejamento, mas
simplesmente mostra que eles tm importncia secundria quando
comparado com os indivduos e interaes, com o software estar
executvel, com a colaborao do cliente e as respostas rpidas a
mudanas e alteraes. Esses conceitos aproximam-se melhor com
a forma que pequenas companhias de Tecnologia da Informao
trabalham e respondem a mudanas.
Para ser realmente considerada gil a metodologia deve
aceitar a mudana ao invs de tentar prever o futuro. O problema
no a mudana em si, mesmo porque ela ocorrer de qualquer
forma. O problema como receber, avaliar e responder s
mudanas.
Enquanto as metodologias geis variam em termos de
prticas e nfases, elas compartilham algumas caractersticas, como
desenvolvimento iterativo e incremental, comunicao e reduo de
produtos intermedirios, como documentao extensiva. Desta
forma existem maiores possibilidades de atender aos requisitos do
cliente, que muitas vezes so mutveis.
37
2.1.5. Entrega Evolutiva

Uma combinao muito interessante entre o modelo em
cascata e o modelo incremental o modelo de entrega evolutiva,
apresentado na Figura 11. Ele uma combinao dos modelos de
Cascata e Prototipagem evolutiva. Nesse modelo, o levantamento de
requisitos feito como um todo, para que seja possvel entender
todo as questes que envolvem o produto a ser construdo, porm,
em pontos bem definidos os usurios podem avaliar as partes do
produto j desenvolvidas, fornecendo realimentao quanto s
decises tomadas, de forma bem similar ao que acontece na
Prototipagem Evolutiva. Isso facilita o acompanhamento dos
projetos, tanto por parte dos gerentes, quanto por parte dos clientes,
que podem acompanhar o que est sendo realizado.

Figura 12: O modelo de ciclo de vida entrega evolutiva.

A principal dificuldade associada ao modelo de entrega
evolutiva o levantamento de requisitos, que deve ser bem feito,
para que a partir disso seja possvel a definio da arquitetura do
produto, que deve ser robusta, mantendo-se ntegra ao longo dos
Requi si tos
Anl ise
Desenho
arquitetni co
Desenho
detal hado
Implementao
Testes Avali ao da
iterao
Proj eto termi nado
Nova iterao
38
ciclos de liberaes parciais. De uma forma geral a arquitetura
chave nesse modelo. Um dos grandes representantes desse modelo
de ciclo de vida o Processo Unificado (PU). Vrios processos, tais
como o RUP (Rational Unified Processo) e o PRAXIS utilizam o PU
como processo base. Esses processos so muito utilizados no
mundo, com vrios casos de sucesso.
Um erro muito comumente cometido pelos defensores dos
mtodos geis afirmar que processos como o RUP e PRAXIS so
baseados no modelo em cascata. Esse um erro grosseiro e
freqente. Embora os Processos geis sejam muito interessantes,
comum a existncia de xiitas que defendem tais mtodos sem
avaliar os prs e contras de cada um dos modelos de ciclo de vida
associados. Normalmente onde os requisitos so conhecidos e
relativamente estveis os processos baseados no modelo de
entrega evolutiva so mais apropriados; para projetos envolvendo
equipes pequenas e cujos requisitos no sejam bem conhecidos ou
sejam muito instveis os processos baseados no modelo
incremental so mais apropriados. De forma geral o bom senso o
melhor termmetro para definio do que mais apropriado em uma
situao, mas um conselho a todos que possam se deparar com
essa situao : nunca acredite em pessoas que defendem
cegamente esse ou aquele processo; como tudo na vida, o
contexto da situao pode determinar o que o mais
apropriado.
2.1.6. Outros Modelos de Ciclo de Vida

Alguns autores, erroneamente em nossa opinio, consideram
como sendo outros modelos de ciclo de vida, o uso de certas
ferramentas e tecnologias especficas. Esse o caso, por exemplo,
de considerar que o Desenvolvimento Baseado em Componentes ou
que o uso de ferramentas RAD sejam modelos de ciclo de vida. No
nosso ponto de vista isso apenas a definio de uso de certas
O modelo de entrega
evolutivo atual e
possui inmeros casos
de sucesso. Muitos dos
defensores dos
processos geis
confundem a entrega
evolutiva com o modelo
em cascata, o que
representa um erro
absurdo!
39
tecnologias e que no geram ciclos de vida diferenciados do que j
foi exposto neste captulo.
2.2. Exerccios

1. Quais so as principais fases do ciclo de vida de um produto
de software?
2. Qual a ligao entre Ciclo de Vida e Processo de Software?
3. Qual a definio para Processo de Software?
4. Quais so os principais subprocessos (tambm conhecidos
como fluxos ou disciplinas) ligados ao desenvolvimento de
software?
5. Descreve o modelo de ciclo de vida denominado Codifica-
Remenda.
6. Quais so os problemas relacionados ao modelo de ciclo de
vida em cascata?
7. Como podemos relacionar o modelo em cascata e o modelo
em espiral?
8. Qual a grande diferena entre o model em espiral e o modelo
incremental?
9. Os mtodos geis so baseados no manifesto gil. Quais so
os conceitos chaves desse manifesto?
10. Como funciona o modelo de entrega evolutiva?
11. Os dois modelos de ciclo de vida recomendados para uso e
mais utilizados atualmente so o modelo incremental e o
modelo de entrega evolutiva. Quando um mais apropriado
que outro?
40
WEBLIOGRAFIA
UNIDADE I
CONCEITOS BSICOS




Pgina da Universidade Aberta do Piau - UAPI
http://www.ufpi.br/uapi

Pgina da Universidade Aberta do Brasil- UAB
http://www.uab.gov.br

Instituto de Engenharia de Software do MIT
http://www.sei.cmu.edu/

Stio de apoio ao livro de Roger Pressman
http://www.rspa.com/

Stio de apoio ao livro de Ian Sommerville
http://www.comp.lancs.ac.uk/computing/resources/IanS/

Stio de apoio ao livro de Wilson de Pdua
http://homepages.dcc.ufmg.br/~wilson/

Relatrios do Standish Group, incluindo dados sobre
desenvolvimento de software
http://www.standishgroup.com
41
REFERNCIAS BIBLIOGRFICAS
UNIDADE I
CONCEITOS BSICOS




ALISTAIR, COCKBURN, Escrevendo Casos De Uso Eficazes,
Editora Bookman, 2003.

ASSOCIAO BRASILEIRA DE NORMAS TCNICAS, ISO/IEC
12207 Tecnologia da Informao Processos de ciclo de vida
de software, Rio de Janeiro: ABNT, 1996.

BERTRAND MEYER, Object-oriented Software Construction,
Prentice-Hall, 2a edio, 1997.

EDSGER W. DIJKSTRA, The humble programmer,
Communications of ACM, volume 15, nmero 10, outubro de 1972,
pginas 859-866.

FREDERICK P. BROOKS, No silver bullet: essence and accidents of
software engineering, Computer Magazine, abril de 1987.

IAN SOMMERVILLE, Engenharia de Software, 6a. Edio,
Addison-Wesley, 2005.

KENDALL SCOTT, Processo Unificado Explicado, Editora
Bookman, 2003.

KENT BECK, Extreme Programming Explained: embrace
change. Boston: AddisonWesley/Longman, 1999.

42
RICHARD FAIRLEY, Software Engineering Concepts, McGraw-
Hill, New York, 1985.

ROGER S. PRESSMAN, Engenharia de Software, 5a. Edio,
McGraw-Hill, So Paulo, 2002.

STEVE MACCONNELL, Rapid Development, Microsoft Press,
1996.

W. WAYT GIBBS, Software's chronic crisis, Scientific American,
Setembro de 1994.

WILSON DE PDUA PAULA FILHO, Engenharia de Software:
Fundamentos, Mtodos e Padres, Editora LTC, 2 Edio, 2003.


43
UNIDADE II
AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA
DE SOFTWARE

RESUMO

Nesta unidade apresentamos os principais fluxos (ou
subprocessos) que guiam a execuo de Projetos de
Desenvolvimento de Software baseados em princpios de
Engenharia. Este captulo totalmente baseado no livro do Prof.
Wilson de Pdua, e no seu Processo, o Praxis, uma vez que o
mesmo possui exemplos ilustrativos de todas as partes que
compem o desenvolvimento de software, aliados a uma definio
precisa das atividades, mtodos e tcnicas relacionados a cada
fluxo.
No Captulo 3 apresentamos o fluxo de Requisitos, onde
devem ser obtidas e registradas informaes relativas ao desejo dos
usurios em relao a um produto de software. Apresentamos
tambm uma breve descrio do processo Praxis, utilizado como
base para as descries dos fluxos desta unidade.
No Captulo 4 apresentamos o fluxo de Anlise, onde devem
ser modelados os conceitos relacionados ao problema identificado a
partir do levantamento de requisitos, realizando assim uma validao
do que foi levantado, alm de iniciarmos a sua modelagem em um
formato mais prximo dos desenvolvedores.
No Captulo 5 apresentamos o fluxo de Desenho, onde deve
ser modelada uma soluo para o problema identificado durante o
Requisito e Anlise. A grande diferena nesse ponto o foco:
enquanto que a Anlise foca no problema, o Desenho foca na
soluo para o problema. Um ponto muito importante nesse fluxo a
definio da arquitetura do produto.
44
No Captulo 6 apresentamos o fluxo de Implementao, onde
devem ser codificadas as partes que iro compor o produto,
utilizando as tecnologias definidas no Desenho.
No Captulo 7 apresentamos o fluxo de Teste, responsvel
pela verificao e validao da implementao desenvolvida.
No Captulo 8 apresentamos o fluxo Gesto de Projetos, onde
deve ser criado o plano de desenvolvimento de software, juntamente
com clculos para gerar estimativas de custo e prazo, alm do
acompanhamento da execuo do mesmo.


45






INTRODUO ENGENHARIA DE SOFTWARE

UNIDADE II ................................................................................................ 43
AS PRINCIPAIS DISCIPLINAS DA ENG. DE SOFTWARE ............. 43
3. Requisitos............................................................................................. 46
3.1. O Processo Praxis......................................................................... 46
3.2. O Fluxo de Requisitos.................................................................. 49
3.3. Exerccios..................................................................................... 55
4. Anlise.................................................................................................. 56
4.1. Exerccios..................................................................................... 59
5. Desenho................................................................................................ 60
5.1. Exerccios..................................................................................... 65
6. Implementao ..................................................................................... 66
6.1. Exerccios..................................................................................... 71
7. Testes.................................................................................................... 72
7.1. Exerccios..................................................................................... 75
8. Gesto de Projetos................................................................................ 76
8.1. Exerccios..................................................................................... 77

SUMRIO DA UNIDADE
46
UNIDADE II
AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA
DE SOFTWARE
3. Requisitos
Nesta unidade iremos apresentar os principais fluxos da
Engenharia de Software. Conforme comentamos, utilizaremos o livro
do Prof. Wilson de Pdua como base nessa explicao. Esse livro
descreve o Processo Praxis, que ser brevemente apresentado a
seguir, para ento darmos incio ao detalhamento dos fluxos ligado
Engenharia de Software.
3.1. O Processo Praxis

O Praxis um processo de software baseado no modelo de
entrega evolutiva. O termo significa PRocesso para Aplicativos
eXtensveis e InterativoS e constitui um processo de
desenvolvimento de software desenhado para projetos com durao
de seis meses a um ano, realizados individualmente ou por
pequenas equipes. Ele voltado para o desenvolvimento de
aplicativos grficos interativos, baseados na tecnologia orientada a
objetos.
Seguindo a arquitetura definida no Processo Unificado, o
Praxis prope um ciclo de vida composto por fases, divididas em
uma ou mais iteraes, e fluxos, que correspondem a disciplinas da
Engenharia de Software. Durante a execuo das fases, diversos
fluxos podem ser necessrios, de acordo com o que descrito nos
scripts das iteraes. A



47
Tabela 1 apresenta a diviso em fases e iteraes,
enquanto a organizao em fluxos descrita na

Tabela 2.




48
Tabela 1: Fases e Iteraes do Processo Praxis.
Fase Iterao Descrio
Concepo Ativao
Levantamento e anlise das necessidades dos usurios e
conceitos da aplicao, em nvel de detalhe suficiente para
justificar a especificao de um produto de software.
Levantamento dos
requisitos
Levantamento das funes, interfaces e requisitos no-
funcionais desejados para o produto.
Elaborao
Anlise dos requisitos
Modelagem conceitual dos elementos relevantes do domnio do
problema e uso desse modelo para validao dos requisitos e
planejamento detalhado da fase de Construo.
Desenho
Implementvel
Definies interna e externa dos componentes de um produto
de software, em nvel suficiente para decidir as principais
questes de arquitetura e tecnologia e para permitir o
planejamento detalhado das liberaes.
Liberao 1..n
Implementao de um subconjunto de funes do produto que
ser avaliado pelos usurios.
Construo
Testes Alfa
Realizao dos testes de aceitao, no ambiente dos
desenvolvedores, juntamente com elaborao da
documentao de usurio e possveis planos de Transio.
Testes Beta Realizao dos testes de aceitao no ambiente dos usurios.
Transio
Operao Piloto
Operao experimental do produto em instalao piloto do
cliente, com a resoluo de eventuais problemas atravs de
processo de manuteno.


Tabela 2: Principais fluxos tcnicos e gerenciais do Praxis.
Natureza Fluxo Descrio
Requisitos
Fluxo que visa a obter um conjunto de requisitos de um
produto, acordado entre cliente e fornecedor.
Anlise
Fluxo que visa a detalhar, estruturar e validar os requisitos de
um produto, em termos de um modelo conceitual do problema,
de forma que eles possam ser usados como base para o
planejamento e controle detalhados do respectivo projeto de
desenvolvimento.
Desenho
Fluxo que visa a formular um modelo estrutural do produto que
sirva de base para a implementao, definindo os
componentes a desenvolver e a reutilizar, assim como as
interfaces entre si e com o contexto do produto.
Implementao
Fluxo que visa a detalhar e implantar o desenho atravs de
componentes de cdigo e de documentao associada.
Tcnicos Testes
Fluxo que visa a verificar os resultados da implementao,
atravs do planejamento, desenho e realizao de baterias de
testes.
Gesto de Projeto Fluxo que visa a planejar e controlar os projetos de software.
Gerenciais
Gesto da Qualidade
Fluxo que visa a verificar e assegurar a qualidade dos produtos
e processos de software.

Apesar de ter sido originalmente destinado utilizao em
projetos didticos em disciplinas de Engenharia de Software, o
Praxis vem sendo usado com sucesso tambm em projetos maiores,
49
alguns envolvendo equipes de at dezenas de pessoas. Conforme
comentado anteriormente, nesta unidade vamos descrever os
principais fluxos tcnicos e gerenciais do processo, uma vez que
eles so similares em quase todos os processos existentes.
3.2. O Fluxo de Requisitos

O fluxo de Requisitos possui atividades que visam a obter o
enunciado completo, claro e preciso dos requisitos de um produto de
software. Os requisitos correspondem a qualquer desejo,
necessidade, restrio ou expectativa dos clientes em relao a um
produto de software. Estes requisitos devem ser levantados pela
equipe do projeto, em conjunto com representantes do cliente,
usurios chaves e outros especialistas da rea de aplicao.
O conjunto de tcnicas empregadas para levantar, detalhar,
documentar e validar os requisitos de um produto forma a
Engenharia de Requisitos. O resultado principal do fluxo de
requisitos um documento de Especificao de Requisitos de
Software (que abreviaremos ERSw). Esse documento possui uma
caracterizao do problema do cliente e que deve ser utilizado para
criao de um produto.
Projetos de produtos mais complexos geralmente precisam de
maior investimento em Engenharia de Requisitos do que projetos de
produtos mais simples, por questes bvias. A Engenharia de
Requisitos tambm mais complexa no caso de produtos novos. O
desenvolvimento de uma nova verso de um produto existente [e
muito ajudado pela experincia dos usurios com as verses
anteriores, uma vez que permite identificar de forma rpida e clara
aquilo que mais importante, o que no pode ser mudado e tudo
aquilo que no funciona e precisa de uma nova soluo urgente. No
caso de um novo produto, difcil para os usurios identificar o que
mais importante, tornando igualmente difcil para os
desenvolvedores entender claramente o que os usurios desejam.
50
Uma boa Engenharia de Requisitos um passo essencial
para o desenvolvimento de um bom produto, em qualquer caso.
Neste captulo descrevemos brevemente as atividades do fluxo de
Requisitos do Praxis. Para garantir ainda mais a qualidade, os
requisitos devem ser submetidos aos procedimentos de controle
previstos no processo, e devem ser verificados atravs das
atividades de Anlise.
Requisitos de alta qualidade so claros, completos, sem
ambigidade, implementveis, consistentes e testveis. Os
requisitos que no apresentem estas qualidades so problemticos:
eles devem ser revistos e renegociados com os clientes e usurios.
A Especificao dos Requisitos do Software o documento
oficial de descrio dos requisitos de um projeto de software. Ela
pode se referir a um produto indivisvel de software, ou a um
conjunto de componentes de software, que formam um produto
quando usados em conjunto (por exemplo, um mdulo cliente e um
mdulo servidor).
As caractersticas que devem estar contidas na Especificao
dos Requisitos do Software incluem:
Funcionalidade: O que o software dever fazer?
Interfaces externas: Como o software interage com as
pessoas, com o hardware do sistema, com outros
sistemas e com outros produtos?
Desempenho: qual o tempo de resposta mximo
permitido dado um contexto de funcionamento, como
por exemplo, 100 usurios realizando emprstimo de
um livro.
Outros atributos: Quais as consideraes sobre
portabilidade, manutenibilidade e confiabilidade que
devem ser observadas?
Restries impostas pela aplicao: existem padres e
outros limites a serem obedecidos, como linguagem de
51
implementao, ambientes de operao, limites de
recursos etc.?
A Figura 13 apresenta as atividades do fluxo de Requisitos do
Praxis. O fluxo iniciado atravs da Determinao do contexto,
que levanta os aspectos dos processos de negcio ou de um
sistema maior que sejam relevantes para a determinao dos
requisitos do produto. A Definio do escopo delimita os problemas
que o produto se prope a resolver.


Figura 13: O Fluxo de Requisitos.

A Definio dos requisitos produz uma lista de todos os
requisitos funcionais e no-funcionais. Estes requisitos so descritos
52
de forma sucinta, ainda sem entrar-se em detalhes. A Tabela 3 exibe
um exemplo de requisitos definidos para um produto responsvel
pelo controle de leitos de hospitais. Normalmente utilizamos o
conceito de Caso de Uso associado s funcionalidades de um
produto.
So tambm identificados os grupos de usurios do produto,
tambm denominados Atores, e as demais restries aplicveis. Um
diagrama de casos de uso exibe os relacionamentos entre atores e
casos de uso, e apresentado na Figura 14. recomendvel, at
este ponto, que os tomadores de deciso do cliente participem do
levantamento dos requisitos. As atividades seguintes cobrem
aspectos mais detalhados, sendo provavelmente mais adequado
que participem os usurios chaves e no necessariamente pessoal
gerencial do cliente. Ela ser revista nesta fase, normalmente com a
participao de um nmero maior de partes interessadas.

Tabela 3: Exemplo de requisitos para um produto de software.
Nr Caso de uso Descrio
1 Gesto de
Hospitais
Cadastros dos Hospitais com leitos controlados
pelo SRLEP.
2 Gesto de Leitos Cadastro dos Leitos hospitalares controlados pelo
SRLEP.
3 Autorizao de
envio para lista
de espera
Registro da autorizao da solicitao para constar
na lista de espera por leitos.
4 Controle de
Internaes
Controle das internaes em leitos, com
possibilidade registro de alta, e conseqente
liberao do leito, alm de transferncias para
outros leitos.
5 Consulta Escala Visualizao de quadro de escala hospitalar.

As trs atividades posteriores correspondem ao detalhamento
dos requisitos de interface, funcionais e no-funcionais. Os dois
primeiros so mostrados como atividades paralelas, pois existem
interaes fortes entre os requisitos de interface e os requisitos
funcionais.
Um Caso de Uso uma
fatia de funcionalidade do
sistema, sem
superposio nem
lacunas, que representam
algo de valor para os
usurios finais.
Um Ator representao
dos usurios e outros
sistemas que interagem
com o produto
Um Diagrama de Casos
de Uso exibe os
relacionamentos entre
atores e casos de uso,
deixando claro que grupos
utilizam quais funes.
53

Figura 14: Exemplo de diagrama de caso de uso.

Durante o Detalhamento dos requisitos de interface so
detalhados os aspectos das interfaces do produto que os usurios
consideram requisitos. Normalmente, feito um esboo das
interfaces de usurio, levantado atravs de um prottipo executvel
ou de estudos em papel. Esses esboos, entretanto, no devem
descer a detalhes de desenho, mas apenas facilitar a visualizao
dos verdadeiros requisitos (por exemplo, que informao a interface
deve captar e exibir). A Figura 15 exibe um esboo de uma interface
de usurio sem amarrao a qualquer tecnologia de implementao.
So tambm detalhadas as interfaces com outros sistemas e
componentes de sistema. No Praxis, o Detalhamento dos requisitos
funcionais utiliza a notao de casos de uso. O fluxo de execuo
das funes descrito de forma padronizada, dentro da
Especificao dos Requisitos do Software.
aconselhvel a
utilizao de um formato
independente de
tecnologia para descrio
das telas de um sistema.
Isso evita uma reduo no
espao das solues.
Utilizar um componente do
tipo Select ou Radio
Button pode bloquear a
viso de desenvolvedor
para solues mais
interessantes!
54
Gesto de Condies de Internao
Pesquisa por Condies de Internao
Condio Insuficincia heptica grave (at 50 caracteres)
<Pesquisar>
Condies de internao recuperadas
Condio Tipo
Insuficincia respiratria grave Primria
Coma mixedematoso Secundria
<Novo> <Alterar>
Condies de Internao
Condio* Insuficincia heptica grave (at 50 caracteres)
Tipo [Primria; Secundria]
<Salvar>
Figura 15: Exemplo de um prottipo de tela independente de
tecnologia.

O Detalhamento dos requisitos no-funcionais completa os
requisitos, descrevendo os requisitos de desempenho e outros
aspectos considerados necessrios para que o produto atinja a
qualidade desejada. Inclui-se aqui tambm o detalhamento de
requisitos derivados de outros tipos de restries (por exemplo,
restries de desenho).
A Classificao dos requisitos determina as prioridades
relativas dos requisitos e avalia a estabilidade e a complexidade de
realizao. Os requisitos aprovados so lanados no Cadastro dos
Requisitos do Software, para que sejam posteriormente registrados
e rastreados seus relacionamentos com tens derivados, em outros
artefatos do projeto.
Finalmente, a Reviso dos requisitos determina se todos
eles satisfazem os critrios de qualidade de requisitos e se a
Especificao dos Requisitos do Software est clara e bem
entendida por todas as partes interessadas.
Na disciplina Requisitos de Software iremos detalhar com
bastante profundidade este fluxo, juntamente com os mtodos e
tcnicas associados.
Na disciplina Requisitos
de Software ser
detalhado o fluxo de
requisitos e anlise.
Iremos realizar diversas
prticas relacionadas ao
tema.
55
3.3. Exerccios

1. Qual o objetivo do fluxo de requisitos?
2. Por que o levantamento de requisitos para produtos novos
geralmente mais difcil que para produtos j existentes?
3. O que deve conter uma Especificao de Requisitos?
4. Quais as atividades de requisitos?
5. Em qual atividade feita uma descrio dos requisitos de
forma sucinta?
6. Como so representados os grupos de usurios do produto?
7. Que notao utilizada para descrio dos requisitos
funcionais?
8. Por que aconselhado fazer um esboo das telas de forma
independente de tecnologia?


56
UNIDADE II
AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA
DE SOFTWARE
4. Anlise
O fluxo da Anlise tem como objetivos:
modelar de forma precisa os conceitos relevantes do
domnio do problema, identificados a partir do
levantamento de requisitos;
verificar a qualidade dos requisitos identificados;
detalhar esses requisitos o suficiente para que atinjam
o nvel de detalhe adequado aos desenvolvedores.
No Praxis, os mtodos de Anlise so baseados na
Tecnologia Orientada a Objetos, resultando em um Modelo de
Anlise do Software, expresso na notao UML.
O Modelo de Anlise deve conter os detalhes necessrios
para servir de base para o desenho do produto, mas deve-se evitar a
incluso de detalhes que pertenam ao domnio da implementao e
no do problema. Quando se usa um Modelo de Anlise orientado a
objetos, os requisitos funcionais so tipicamente descritos e
verificados atravs dos seguintes recursos de notao:
Os casos de uso descrevem o comportamento
esperado do produto. Os diagramas de casos de uso
descrevem os relacionamentos dos casos de uso entre
si e com os atores.
As classes representam os conceitos do mundo da
aplicao que sejam relevantes para a descrio mais
precisa dos requisitos, exibindo os relacionamentos
entre essas.
As realizaes dos casos de uso mostram como
objetos das classes descritas colaboram entre si para
57
realizar os principais roteiros que podem ser
percorridos dentro de cada caso de uso.

Figura 16: O Fluxo de Anlise.

A Figura 16 exibe as atividades da Anlise. Ela inicia pela
Identificao das classes, na qual so analisados os fluxos dos
casos de uso e outros documentos relevantes em relao ao produto
desejado. Os conceitos candidatos a classes so localizados, e
filtrados de acordo com vrios critrios. Prossegue com a
Organizao das classes, que organiza as classes em pacotes
lgicos (agrupamentos de classes correlatas) e lhes atribui os
esteretipos de entidade, fronteira e controle, dependendo do papel
que desempenham no modelo. A Identificao dos
58
relacionamentos determina os relacionamentos de vrios tipos que
podem existir entre os objetos das classes identificadas..
Em seguida, a Identificao dos atributos levanta os
atributos de anlise, isto , propriedades que fazem parte do
conceito expresso pela classe. Todas as atividades descritas
anteriormente do origem ao diagrama de classes contendo todos
os detalhamentos de atributos, diviso em pacotes e com
especificao dos relacionamentos. Um exemplo de diagrama
contendo essas informaes exibido na Figura 17.

Figura 17: Exemplo de diagrama de classes exibindo classes,
atributos e relacionamentos.

Em paralelo, a Realizao dos casos de uso verifica os
fluxos dos casos de uso, representando-os atravs de diagramas de
interao. Estes mostram como os fluxos so realizados atravs de
O diagrama de classe
fornece uma viso geral
do sistema e representa
um artefato imprescindvel
no desenvolvimento.
59
trocas de mensagens entre os objetos das classes encontradas. Isso
ajuda a localizar imprecises e outros tipos de problemas nos fluxos
e permite definir as operaes das classes de anlise.
Por fim, a Reviso da anlise valida o esforo de Anlise e o
correspondente esforo de Requisitos. Podem acontecer vrias
revises informais, individuais ou em grupo (por exemplo, dentro de
uma oficina de detalhamento dos requisitos).
4.1. Exerccios

1. Qual o objetivo do fluxo de anlise?
2. Quais recursos da UML so utilizados para descrever os
requisitos em um modelo de anlise?
3. O que descrito no diagrama de classes?
4. O que a realizao dos casos de uso?
5. Que locais so consultados para se tentar identificar classes?






60
UNIDADE II
AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA
DE SOFTWARE
5. Desenho

O fluxo de Desenho (design ou projeto) tem por objetivo
definir uma estrutura implementvel para um produto de software
que atenda aos requisitos associados. Sua principal diferena para a
anlise est justamente no foco: a Anlise visa modelar os conceitos
relacionados ao domnio do problema, enquanto o Desenho visa
modelar os conceitos relacionados uma soluo para o problema.
Alguns processos de software prescrevem que a Anlise e o
Desenho devam ser um nico fluxo, com o intuito de modelar a
soluo para o problema. Conforme detalhado aqui, o Praxis separa
bem esses dois conceitos. Nesse caso ento, o desenho de um
produto de software deve considerar os seguintes aspectos:
o atendimento dos requisitos no-funcionais, como os
requisitos de desempenho e usabilidade;
a definio de classes e outros elementos de modelo em
nvel de detalhe suficiente para a respectiva implementao;
a decomposio do produto em componentes cuja
construo seja relativamente independente, de forma que
eventualmente possa ser realizada por pessoas diferentes,
possivelmente trabalhando em paralelo;
a definio adequada e rigorosa das interfaces entre os
componentes do produto, minimizando os efeitos que problemas em
cada um dos componentes possam trazer aos demais elementos;
a documentao das decises de desenho, de forma que
estas possam ser comunicadas e entendidas por quem vier a
implementar e manter o produto;
61
a reutilizao de componentes, mecanismos e outros
artefatos para aumentar a produtividade e a confiabilidade;
o suporte a mtodos e ferramentas de gerao semi-
automtica de cdigo.
O foco do fluxo de Desenho a concepo de estruturas
robustas, que tornem a implementao mais confivel e produtiva.
Tipicamente, as atividades de Desenho so realizadas por grupos
bastante pequenos de profissionais experientes nas tcnicas deste
fluxo; a implementao correspondente pode ser delegada a
profissionais no necessariamente proficientes em Desenho, mas
conhecedores do ambiente de implementao, e treinadas nas
respectivas tcnicas.
62

Figura 18: O Fluxo de Desenho.

A Figura 18 exibe as atividades do fluxo de Desenho. Ele
inicia pela atividade de Desenho arquitetnico, que trata de
aspectos estratgicos de desenho. Ela define a diviso do produto
em subsistemas, escolhendo-se as tecnologias mais adequadas. As
decises sobre tecnologia devem viabilizar o atendimento dos
requisitos no-funcionais e a execuo do projeto dentro do prazo e
custos estimados. Uma deciso fundamental a escolha do
ambiente definitivo de implementao, se isso j no fizer parte das
restries de desenho constantes da Especificao dos Requisitos
63
do Software. Faz parte dessa atividade tambm a definio
estratgica e estrutural da documentao para usurios.
Um exemplo da escolha do ambiente definitivo de
implementao seria: vamos utilizar Java, na verso 1.6, com o
Hibernate 2.1, utilizando o Framework Struts 2.0, que ser
executado no container Tomcat 5.5. Todas essas decises devem
ser registradas e comunicadas equipe.

Figura 19: Exemplo de uma tela no ambiente final de
implementao.

O Desenho das interfaces trata do desenho das interfaces
reais do produto em seu ambiente definitivo de implementao. Essa
atividade baseada nos requisitos de interfaces constantes da
Especificao dos Requisitos do Software. Esses requisitos so
detalhados, levando-se em conta as caractersticas do ambiente de
implementao e os resultados dos estudos de usabilidade. Parte do
cdigo fonte das classes correspondentes figura como artefato
resultante desta atividade, pois em muitos ambientes mais fcil
desenhar os elementos grficos das interfaces de usurio dentro do
ambiente de implementao, extraindo desse cdigo o respectivo
modelo por meio de ferramentas. Um exemplo do detalhamento da
interface de usurio independente de tecnologia, exibido na Figura
15, apresentado na Figura 19 utilizando a tecnologia escolhida
para a implementao do software.
A arquitetura de um
produto corresponde a
todas as tecnologias
empregadas para sua
construo, aliadas a
forma de interconexo
entre tais tecnologias.

Uma empresa com
diversos produtos
normalmente segue a
arquitetura j existente
para produtos novos.

Quando h a necessidade
de mudarmos de
tecnologia, necessrio
muito estudo e testes para
se obter o nvel de
entendimento e
maturidade necessrio
para implementar um novo
projeto.
64
O Detalhamento dos casos de uso resolve os detalhes dos
fluxos dos casos de uso de desenho, considerando os componentes
reais das interfaces. Todos os fluxos alternativos devem ser
detalhados, inclusive os que consistem de emisso de mensagens
de exceo ou erro. Se esta atividade for feita de forma completa,
pode-se deixar a cargo de profissionais de redao tcnica a
confeco da documentao para usurios, e at das mensagens
aos usurios. Os fluxos dos casos de uso desenho so tambm a
base para o desenho dos testes de aceitao, e a referncia para os
implementadores quanto ao comportamento desejado para o
produto.
A atividade de Desenho das entidades transforma as
classes de entidade do Modelo de Anlise nas classes
correspondentes do Modelo de Desenho. Inclui-se aqui a
considerao de possvel reutilizao dessas classes, ou de
transformao delas em componentes fisicamente distintos. Muitos
detalhes irrelevantes para a Anlise devem ser ento decididos,
como a visibilidade das operaes e a navegabilidade dos
relacionamentos. Inclui-se aqui tambm a tomada de decises sobre
como sero representados os relacionamentos; no caso de
multiplicidades maiores que um, geralmente essa representao
envolve o desenho de colees de objetos.
A atividade de Desenho da persistncia trata da definio de
estruturas externas de armazenamento persistente, como arquivos e
bancos de dados. Dois problemas devem ser resolvidos: a definio
fsica das estruturas persistentes externas, como o esquema de um
banco de dados, e a realizao de uma ponte entre o modelo de
desenho orientado a objetos e os paradigmas das estruturas de
armazenamento, que geralmente so de natureza bastante
diferente. Esta ponte feita pela camada de persistncia. As classes
desta camada so desenhadas nesta atividade; entretanto, como
uma camada de persistncia bem desenhada altamente
reutilizvel, muitas vezes a atividades se reduz a adaptaes de
componentes j existentes.
Um framework ou
arcabouo uma
abstrao que une
cdigos comuns entre
vrios projetos de
software, provendo uma
funcionalidade genrica e
facilitando o seu uso.
Scott Ambler discute sobre
camadas de persistncia
em um artigo referenciado
no mundo inteiro. Confira
na Webliografia!
65
A Realizao dos casos de uso determina como os objetos
das classes de desenho colaboraro para realizar os casos de uso.
As classes da camada de controle contero o cdigo que amarra
essas colaboraes, de maneira a obter-se o comportamento
requerido pelos casos de uso de desenho. Diagramas de interao
so usados para descrever as colaboraes. Esta atividade permite
validar muitas das decises tomadas nas atividades anteriores.
Classes utilitrias, agrupadas em uma camada de sistema, ajudam a
abstrair aspectos que sejam comuns s realizaes de diferentes
casos de uso.
Casos de uso e classes de desenho so repartidos entre as
liberaes, procurando-se mitigar primeiro os maiores riscos, obter
realimentao crtica dos usurios a intervalos razoveis, e
possivelmente dividir as unidades de implementao de forma
conveniente, entre a fora de trabalho.
Finalmente, a Reviso do desenho valida o esforo de
Desenho, confrontando-o com os resultados dos Requisitos e da
Anlise. Dependendo da iterao, o Praxis padro prev revises
tcnicas da Descrio do Desenho, ou inspees, que focalizam
principalmente o Modelo de Desenho.
5.1. Exerccios

1. Qual a principal diferena entre a Anlise e o Desenho?
2. Quais so os principais aspectos a considerar no Desenho?
3. Quais as caractersticas dos grupos que realizam Desenho
em uma organizao desenvolvedora de software?
4. O que vem a ser a arquitetura de um produto?
5. O que uma camada de persistncia?
6. O que feito de adicional no desenho das entidades, em
relao ao que existe na Anlise?
No fluxo de desenho
devemos identificar os
padres a serem seguidos
no projeto. Padres so
solues bem conhecidas
para problemas
recorrentes.

So exemplos de
problemas recorrentes:
como criar uma classe e
garantir que haver
somente uma instncia
dela ativa no sistema? O
padro Singleton nos
ensina como resolver esse
problema de forma
simples, sem termos que
perder tempo pensando
nessa soluo.

Nas referncias citamos o
livro mais famoso
relacionado a padres,
escrito por quatro
profissionais altamente
reconhecidos no mundo e
citados como sendo a
Gangue dos Quatro (Gang
Of Four GoF).
66
UNIDADE II
AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA
DE SOFTWARE
6. Implementao
O fluxo de Implementao detalha os componentes previstos
no desenho, descrevendo todos os componentes de cdigo fonte e
cdigo binrio, em nvel de linguagem de programao ou de acordo
com as tecnologias escolhidas, que podem at no incluir
programao diretamente. A implementao inclui as seguintes
tarefas:
planejamento detalhado da implementao das
unidades de cada iterao;
implementao das classes e outros elementos do
modelo de desenho, em unidades de implementao,
geralmente constitudas de arquivos de cdigo fonte;
verificao das unidades, por meio de revises,
inspees e testes de unidade;
compilao e ligao das unidades;
integrao das unidades entre si;
integrao das unidades com componentes
reutilizados, adquiridos de terceiros ou reaproveitados
de projetos anteriores;
integrao das unidades com os componentes
resultantes das liberaes anteriores.
A integrao comentada acima nada mais que a ligao de
um componente desenvolvido com outro que necessite dos seus
servios.
Consideramos que durante a implementao gerada a
documentao de uso do produto. Esta documentao inclui
67
manuais de usurios, ajuda on-line, stios Web integrados ao
produto, material de treinamento, demonstraes e outros recursos.
O fluxo de Implementao contm um grupo de atividades de
implementao normal, e duas atividades de categoria parte, que
so as atividades de Documentao de usurio e Prototipagem.


Figura 20: O Fluxo de Implementao.

A Figura 20 exibe as atividades do Fluxo de Implementao.
Ele inicia com o Desenho detalhado, que preenche os detalhes
restantes do Modelo de Desenho, no nvel necessrio para guiar a
68
codificao. Nessa reviso so conferidos os detalhes de interfaces,
lgica e mquinas de estado das operaes.

Figura 21: Exemplo de uma entidade codificada na linguagem Java.

A traduo do desenho detalhado no cdigo de uma ou mais
linguagens de programao feita na atividade de Codificao. A
Figura 21 exibe o exemplo de uma entidade codificada na linguagem
Java. Essa codificao normalmente feita utilizando uma IDE
(Integrated Development Enviroment), que so ferramentas para
desenvolvimento que incluem uma srie de bibliotecas, atalhos,
wizards e outras funcionalidades integradas, de forma a tornar mais
fcil a vida do desenvolvedor. As unidades de cdigo fonte
produzidas so submetidas a uma reviso de cdigo, para eliminar
os defeitos que so introduzidos por erros de digitao ou de uso da
linguagem. Essa reviso tambm deve ser feita pelos autores,
possivelmente com a ajuda de outros programadores. As unidades
de cdigo fonte so transformadas em cdigo objeto na por meio da
compilao.
O uso de linguagens
orientadas a objetos virou
um padro mundial de
programao atualmente.
Linguagens como C e
Java so, disparadas, as
linguagens mais utilizadas
para o desenvolvimento
de novos sistemas.
69
As prximas atividades so: a Inspeo de implementao e
os Testes de unidade. A Inspeo de implementao verifica, de
forma rigorosa, o desenho detalhado e o cdigo, por meio de um
grupo de revisores pares dos autores.
Os Testes de unidade so feitos usando-se componentes de
teste que devem tambm ter sido desenhados, revistos, codificados
e compilados nas atividades anteriores. Um arcabouo para teste
muito utilizado atualmente a famlia xUnit. Existem arcabouos
especficos para Java (JUnit), para C (CUnit), para Delphi (DUnit),
dentre outros. Esses arcabouos provm facilidades para se criar
classes de teste, disponibilizando mecanismos para execuo dos
testes a partir de interfaces grficas, facilidades para comparao de
valores, agrupamento de testes e etc. Um teste de unidade nada
mais que uma classe que invoca mtodos de outra classe e
verifica se essa ativao, com certos parmetros, gera a resposta
correta, previamente conhecida. Um exemplo de um teste de
unidade exibido na Figura 22. Essa classe um teste para a
classe tringulo, que possui um mtodo, denominado classifica, que
retorna o tipo do tringulo. Podemos facilmente notar que em cada
teste existe a criao de um objeto tringulo, com certos valores
para seus vrtices, seguido da chamada ao mtodo que retorna o
tipo do tringulo e a posterior comparao desse resultado com o
valor esperado.
Embora bem menos formais que os testes de integrao e
aceitao, os resultados desses testes devem pelo menos ser
registrados em relatrios simplificados. A ordem de execuo destas
atividades definida pela convenincia de cada projeto.
A Integrao, finalmente, liga as unidades implementadas
com os componentes construdos em liberaes anteriores,
reutilizados de projetos anteriores ou adquiridos comercialmente. O
cdigo executvel resultante passa ao fluxo de Testes, para
realizao dos testes de integrao.
A atividade de Documentao de usurio tem como principal
objetivo produzir uma documentao que auxilie o uso do sistema
70
por parte dos usurios. Em certos tipos de aplicativos, como os
sistemas baseados em Web, esta atividade no gera documentos
separados, e sim gabaritos para a gerao de pginas que so
misturadas aos relatrios produzidos, de acordo com a tecnologia
empregada.


Figura 22: Um exemplo de teste de unidade.

A atividade de Prototipagem tambm representa uma categoria
parte. Ela executa as mesmas atividades da implementao normal,
mas de maneira informal e sem maiores preocupaes com
padronizao e documentao, pois o cdigo resultante sempre
descartvel.

/**
* Testa a classe triangulo.
*/
public class TestTriangulo extends TestCase {

/**
* Construtor padrao.
*/
public TestTriangulo() {
}

public void testeEquilatero()
{
Triangulo t = new Triangulo(3,3,3);
String result = t.classifica();
assertEquals(result, "EQUILATERO");
}

public void testeIsosceles() {
Triangulo t = new Triangulo(3, 3, 4);
String result = t.classifica();
assertEquals(result, "ISOSCELES");
}

public void testeEscaleno()
{
Triangulo t = new Triangulo(3,4,5);
String result = t.classifica();
assertEquals(result, "ESCALENO");
}

}
71
6.1. Exerccios

1. Qual o objetivo do fluxo de Implementao?
2. O que significa integrar no fluxo de Implementao?
3. Em qual atividade feito a programao utilizando alguma
linguagem ou tecnologia?
4. O que so as IDEs?
5. O que um teste de unidade?
6. O que a documentao de usurio? Em qual atividade ela
desenvolvida?
72
UNIDADE II
AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA
DE SOFTWARE
7. Testes
O Teste de Software a verificao dinmica do
funcionamento de um programa utilizando um conjunto finito de
casos de teste, adequadamente escolhido dentro de um domnio de
execuo infinito, contra seu comportamento esperado. Nesse
conceito existem alguns elementos chaves que merecem um maior
detalhamento:
dinmica: o teste exige a execuo do produto, embora
algumas de suas atividades possam ser realizadas
antes do produto estar operacional;
conjunto finito: o teste exaustivo geralmente
impossvel, mesmo para produtos simples;
escolhido: necessrio selecionar testes com alta
probabilidade de encontrar defeitos, preferencialmente
com o mnimo de esforo;
comportamento esperado: para que um teste possa ser
executado necessrio saber o comportamento
esperado, para que ele possa ser comparado com o
obtido.
No Praxis existem diversos conjuntos de teste, tambm
conhecidos como baterias de teste. Cada um desses conjuntos est
relacionado com uma determinada iterao do processo. As
principais baterias de teste existente so: testes de aceitao, testes
de integrao e testes de unidade.
Um caso de teste especifica como deve ser testado uma
parte do software. Essa especificao inclui as entradas, sadas
esperadas, e condies sob as quais os testes devem ocorrer. Um
exemplo para um caso de teste para um login invlido apresentado
Na disciplina Qualidade de
Software ser detalhado o
fluxo de teste e realizado
diversas prticas
relacionadas ao tema.
73
na Tabela 5. Um procedimento de teste detalha as aes a serem
executadas em um determinado caso de teste. A Tabela 4 exibe o
Procedimento de Teste de Login. Observe que um caso de teste s
faz sentido se for especificado o(s) procedimento(s) de teste
associado(s). Sem essa associao no possvel determinar o que
deve ser feito com as entradas especificadas no caso de teste.
Observe tambm que o procedimento de teste independente dos
dados utilizados nos casos de teste.
Tabela 4: Exemplo de Procedimento de Teste.
Identificao Procedimento de Teste Login
Objetivo Efetuar o login de um usurio no Merci.
Requisitos
especiais
A TelaPrincipal deve estar no estado SEM
USUARIO.
Fluxo
1. Preencher o campo login e senha
2. Pressionar o boto login.

Tabela 5: Exemplo de Caso de Teste.
Identificao Login invlido com caracteres no permitidos
Itens a testar Verificar se a tentativa de login utilizando um
identificador invlido, contendo caracteres no
permitidos, exibe a mensagem apropriada.
Campo Valor
Login pasn! Entradas
Senha aaaa
Campo Valor
Login pasn!
Senha aaaa (exibida com *s)
Sadas
esperadas
Mensagem O campo login deve ter no mnimo 2 e
no mximo 8 caracteres alfabticos.
Estado
alcanado
SEM USUARIO
Ambiente Banco de dados de teste.
Procedimentos Procedimento de Teste Login
Dependncias No aplicvel.

74
O fluxo de teste tem dois grandes grupos de atividades para
cada bateria a ser desenvolvida: preparao e realizao. O plano
da bateria elaborado durante a preparao, juntamente com o
desenho das especificaes de cada teste. Durante a realizao, os
testes so executados, os defeitos encontrados so, se possvel,
corrigidos e os relatrios de teste so redigidos. A preparao e
realizao de cada bateria correspondem a uma execuo completa
do fluxo de Testes. As atividades do Fluxo de Teste so exibidas na
Figura 23.

Figura 23: O Fluxo de Teste.

O grupo de preparao compreende as atividades de
Planejamento, que produz o plano de testes da bateria, e Desenho,
75
que produz as respectivas especificaes. O grupo de realizao
formado pelas demais atividades: Implementao, que monta o
ambiente de testes; Execuo, que os executa efetivamente,
produzindo os principais relatrios de testes; Verificao do trmino,
que determina se a bateria pode ser considerada como completa; e
Balano final, que analisa os resultados da bateria, produzindo um
relatrio de resumo.
Tipicamente, uma organizao comea a implementar o fluxo
de teste pelas baterias de testes de aceitao. Esse tipo de teste
tem por objetivo validar o produto, ou seja, verificar se ele atende
aos requisitos identificados. Na medida em que a cultura da
organizao absorva esses testes, passa a preparar e realizar
tambm os testes de integrao.
7.1. Exerccios

1. O que o teste de software?
2. O que um procedimento de teste? O que um caso de
teste? Qual a ligao que existe entre esses dois conceitos?
3. As atividades de teste so divididas em dois grandes grupos.
Quais so eles?
4. Quais so os objetivos do teste de aceitao?
Na Webliografia
apresentamos o stio do
Brazilian Software Testing
Qualification Board, que
responsvel pela
Certificao Brasileira de
Teste de Software. Essa
certificao atribuda ao
profissional que
aprovado na prova e
garante assim que ele
possui conhecimento na
rea. De acordo com
diversas pesquisas de
mercado feitas
recentemente, os
profissionais de teste
esto entre os mais
procurados e mais bem
remunerados profissionais
de informtica do mundo.
76
UNIDADE II
AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA
DE SOFTWARE
8. Gesto de Projetos
Este captulo trata dos principais mtodos de gesto de
projetos de desenvolvimento de software. Os seguintes tpicos so
brevemente apresentados aqui:
os procedimentos de gesto dos requisitos, que
regulam o cadastramento, a manuteno e a alterao
dos requisitos de um projeto de software;
os procedimentos de planejamento de projetos, que
tratam da previso de tamanho, esforos, recursos,
prazos e riscos de um projeto de software;
os procedimentos de controle de projetos, que tratam
do acompanhamento do progresso e dos riscos de um
projeto, assim como do replanejamento e do balano
final.
A Figura 24 mostra um diagrama de alto nvel de abstrao do
fluxo de Gesto de Projetos, onde cada subfluxo aparece como uma
atividade. Cada subfluxo expandido em atividades mais
detalhadas, mas que no sero apresentadas neste trabalho. Iremos
detalhar parte desses subfluxos nas disciplinas subseqentes do
curso. A Gesto de Requisitos refere-se ao processo de
acompanhamento dos requisitos durante todo decorrer do projeto,
verificando a necessidade de alteraes, analisando o impacto
causado em casos como esse e calculando tempo e esforo
necessrio para tal realizao. O Planejamento de Projetos refere-se
ao processo de estimar os recursos, esforo e prazo necessrio para
se desenvolver um software ou parte dele, com base nos dados
histricos mantidos pela organizao. O Controle de Projeto refere-
se s tarefas de verificao comumente executadas durante o
Na disciplina Qualidade de
Software ser detalhado o
fluxo de teste e realizadas
diversas prticas
relacionadas ao tema.
77
desenvolvimento e ao monitoramento dos riscos e da evoluo
esperada, sempre prescrevendo aes quando o estimado diferir
muito do planejado.
Na prxima unidade apresentamos um exemplo de um
processo de software, ressaltando suas atividades relacionadas
gesto do projeto. Embora sejam atividades simples, poderemos
visualizar como essas atividades podem auxiliar o acompanhamento
do projeto, fornecendo uma viso geral do que foi realizado e ainda
existe a ser feito.

Figura 24: O Fluxo de Gesto de Projetos.

8.1. Exerccios

1. O que vem a ser a Gesto de Requisitos?
2. O que o Planejamento de Projeto?
3. Quais so as aes associados ao Controle de Projeto?
Na Webliografia
apresentamos o stio do
Project Management
Institute - PMI. O PMI
uma entidade mundial
sem fins lucrativos voltado
definio de boas
prticas do gerenciamento
de projetos.
78
WEBLIOGRAFIA
UNIDADE II
AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA
DE SOFTWARE



Stio de apoio ao processo Praxis, com exemplos da aplicao dos
fluxos em um exemplo real de desenvolvimento
http://homepages.dcc.ufmg.br/~wilson/

Pgina de Scott Ambler com boas prticas para o desenvolvimento
de software
http://www.ambysoft.com/

STORM (Software Testing Online Resources). Stio com diversos
materiais sobre testes, desde ferramentas, artigos, livros, etc.
http://www.mtsu.edu/~storm/

Project Management Institute (PMI)
http://www.pmi.org/

Certificao Brasileira de Teste de Software
http://www.bstqb.org.br/



79
REFERNCIAS BIBLIOGRFICAS
UNIDADE II
PRINCIPAIS DISCIPLINAS DA ENGENHARIA DE
SOFTWARE



ALISTAIR, COCKBURN, Escrevendo Casos De Uso Eficazes,
Editora Bookman, 2003.

BERTRAND MEYER, Object-oriented Software Construction,
Prentice-Hall, 2a edio, 1997.

GLENFONRD MYERS, The art of the software testing, John Wiley
& Sons, 1979.

GRADY BOOCH, JAMES RUMBAUGH, IVAR JACOBSON, UML:
Guia do Usurio, Traduo da 2 edio, Editora Campus, 2000.

IEEE, Guide to the Software Engineering Body of Knowledge
(SWEBOK), 2004, editores: Alain Abran e James W. Moore.

KENDALL SCOTT, Processo Unificado Explicado, Editora
Bookman, 2003.

WILSON DE PDUA PAULA FILHO, Engenharia de Software:
Fundamentos, Mtodos e Padres, Editora LTC, 2 Edio, 2003.

80
UNIDADE III
UM EXEMPLO DE UM PROCESSO DE
SOFTWARE

RESUMO

Nesta unidade apresentamos um processo de software
baseado nos princpios da agilidade, alm de apresentarmos seu
uso para uma tarefa simples.
No Captulo 11 apresentamos as prescries do processo
SCRUM, que vem se destacando no cenrio industrial de
desenvolvimento de software, sendo cada dia mais utilizado por
diversas organizaes. Apresentamos os principais papis
associados ao seu uso, alm das cerimnias previstas durante sua
utilizao, detalhando os artefatos que devem ser gerados.
No Captulo 12 apresentamos um exemplo da aplicao do
SCRUM para guiar a execuo de um projeto simples, ilustrando
assim como utilizar o processo para qualquer atividade em que se
deseje ter mais controle sobre sua execuo.

81






INTRODUO ENGENHARIA DE SOFTWARE


UNIDADE III ............................................................................................... 80
9. Um Exemplo de um Processo de Software.......................................... 82
9.1. Os Papis...................................................................................... 84
9.2. As Cerimnias.............................................................................. 85
9.2.1. A Reunio Inicial ................................................................. 85
9.2.2. A Reunio de Planejamento................................................. 89
9.2.3. A Reunio Diria.................................................................. 97
9.2.4. Acompanhamento do Projeto............................................... 97
9.2.5. Apresentao do Sprint ........................................................ 98
9.2.6. Retrospectiva........................................................................ 99
9.3. Finalizao ................................................................................... 99
9.4. Exerccios................................................................................... 100
10. Aplicando o SCRUM..................................................................... 102
10.1. O Exemplo ............................................................................. 102
10.2. Discusso sobre o uso do Scrum............................................ 106
10.3. Exerccios............................................................................... 107


SUMRIO DA UNIDADE
82
UNIDADE III
UM EXEMPLO DE UM PROCESSO DE
SOFTWARE

9. Um Exemplo de um Processo de Software

Scrum um processo gil para gerenciamento e
desenvolvimento de projetos. Esse mtodo foi primeiro descrito por
Takeuchi e Nokata em um trabalho entitulado The New Product
Development Game em 1986 pela Harvard Business Review que
definia um mtodo de desenvolvimento de alto desempenho
apropriado para pequenas equipes. Jeff Sutherland, John
Scumniotales e Jeff McKenna conceberam, documentaram e
implementaram o Scrum, na empresa Easel Corporation em 1993,
incorporando estilos de gerenciamento observados por Takeuchi e
Nonaka. Em 1995, Ken Schwaber formalizou a definio de Scrum e
ajudou a implant-lo no desenvolvimento de software em todo o
mundo.
O Scrum utilizado com sucesso em diversas empresas de
desenvolvimento de software. Porm este mtodo pode ser utilizado
em qualquer contexto em que uma equipe, composto por diversas
pessoas, necessitem trabalhar juntas para atingir um objetivo
comum. Empresas como a Microsoft, Yahoo, Google, Philips,
Siemens, Nokia e vrias outras usam o Scrum como mtodo de
desenvolvimento na confeco de softwares comerciais,
desenvolvimento interno, projetos de preo fixo, aplicaes
financeiras, vdeo games, websites e muitas outras aplicaes.
Ken Schwaber define o Scrum como um guia geral de como
fazer desenvolvimento de produtos, com a finalidade de fazer a
equipe pensar diferente. Segundo ele o desenvolvimento de
Scrum uma disposio
de jogadores de um time
de Rugby, utilizada para
reincio do jogo em certos
casos.
83
produtos uma tarefa complexa e no deve depender de um
conjunto de regras, pois elas no so suficientes para todas as
circunstncias. A equipe deve descentralizar as decises, porque
provavelmente no haver uma nica resposta para cada tipo de
questionamento.
Scrum um mtodo interativo e incremental, baseado no
modelo de ciclo de vida interativo, onde o foco principal est na
entrega do produto, no menor tempo possvel. Isso permite uma
rpida e contnua inspeo do software em produo. As
necessidades do negcio que determinam as prioridades do
desenvolvimento do sistema. As equipes se auto-organizam para
definir a melhor maneira de entregas as funcionalidades de maior
prioridade. Em tempos ajustveis possvel analisar o software em
produo, decidindo se ele avana no processo ou se deve ser
melhorado.
Para uma boa adoo do mtodo Scrum em uma empresa
necessrio que ela tenha uma cultura de fazer as coisas de modo
diferente, mas que necessita tambm de muita disciplinada, uma vez
que no haver muitas regras e nem interferncia externa na
execuo das tarefas.
A evoluo do desenvolvimento de um sistema feito com
base em uma srie de perodos definidos de tempo, chamados
Sprints, que variam, preferencialmente de 2 a 4 semanas. Durante o
esse tempo os requisitos so detalhados, o produto projetado,
codificado e testado. Ao final de cada Sprint feita uma avaliao do
que estava programado, assim o acompanhamento feito em curtos
espaos de tempo.
O desenvolvimento feito de forma paralela em detrimento do
desenvolvimento seqencial (modelo de ciclo de vida em cascata),
ou seja, as equipes fazem um pouco de cada coisa, todo o tempo.
Para a descrio do Scrum vamos apresentar os papis
relacionados ao seu uso, em seguida as principais cerimnias que
so prescritas pelo processo. Uma cerimnia um ritual com
formalidades a serem seguidas, lembrando sempre que o objetivo
O Scrum utiliza o modelo
de ciclo de vida
incremental, conforme
discutido anteriormente.
Embora os Processos
geis prescrevam menos
burocracia no seu uso,
eles exigem alguma
burocracia e no segui-la
significa anarquia!
84
dos processos geis reduzir ao mximo o trabalho burocrtico.
Apresentaremos juntamente com as cerimnias os principais
artefatos produzidos, exibindo alguns exemplos prticos do mesmo.
9.1. Os Papis

O Scrum possui trs papis associados sua execuo: o
Scrum Master, o Product Owner e a Equipe de
Desenvolvimento.
O Product Owner o membro com maior conhecimento das
funcionalidades do produto, decidindo as datas de lanamento e
contedo. Ele prioriza as funcionalidades de acordo com o valor de
mercado, mas para isso deve entender o produto a ponto de
priorizar sem gerar problemas. Da mesma forma, ele tem a tarefa
contnua de ajustar as funcionalidades e prioridades, revendo
descries e conversando com os membros da equipe sempre que
uma dvida surgir. fundamental para o sucesso de um projeto a
presena de um Product Owner com domnio do problema.
Idealmente a pessoa com tal responsabilidade deveria ser um
representante dos clientes do produto, embora em casos
excepcionais um desenvolvedor possa assumir esse papel, devendo
assim manter contato permanente com os clientes reais.
O Scrum Master representa a gerncia para o projeto, ao
mesmo tempo em que responsvel pela aplicao dos valores e
prticas do Scrum. Ele deve manter uma vigilncia contnua sobre o
uso correto das prescries do Scrum, garantindo assim a disciplina
de todos os membros da equipe. Embora os processos geis
tenham um mnimo de burocracia, ainda existe burocracia a ser
seguida. No segui-la pode levar ao caos e a mais completa
anarquia no desenvolvimento.
Embora o Scrum Master seja uma espcie de gerente do
projeto, removendo todo e qualquer obstculo que atrapalhe o
trabalho da equipe e devendo ter bom relacionamento com os nveis
mais altos da organizao, ele tambm deve ter conhecimento
O Scrum Mster o papel
chave no Scrum. Ele deve
garantir o uso do processo
e eliminar interferncias
externas!
85
tcnico suficiente para entender todo o desenvolvimento e ajudar
sempre que necessrio.
A Equipe no Scrum normalmente composta de 5 a 9
membros, embora o Scrum possa ser aplicado tanto com mais
colaboradores, quanto com um colaborador apenas. A diferena
que aplicar o Scrum com um membro apenas torna sem sentido
algumas das prticas previstas no processo. No entanto, ainda
assim o seu uso garante um controle nas atividades sendo
executadas e um conhecimento na produtividade, fatos esse que s
tem a acrescentar a qualquer tipo de trabalho. Os membros da
equipe devem ser multifuncionais, ou seja, eles devem ser capazes
de executar diversos tipos de tarefas, desde a modelagem at o
teste das funcionalidades. Em alguns casos possvel associar
colaboradores a tarefas especficas, mas isso no deve ser utilizado
de modo contnuo, pois pode gerar o que chamamos de ilhas de
conhecimento, onde apenas uma pessoa entende sobre
determinado aspecto. Essa caracterstica pssima para um projeto
e deve ser evitada sempre que possvel, sendo uma das premissas
bsicas da agilidade: o cdigo coletivo! A equipe deve ser auto-
organizada, ou seja, cada um escolhe o que quer fazer. Uma
caracterstica importante da equipe que ela deve sentar junto e se
ajudar sempre que necessrio, pois isso a premissa bsica para o
trabalho em conjunto.
9.2. As Cerimnias

As cerimnias referem-se aos rituais que devem ser seguidos
no uso do processo. As principais cerimnias previstas no Scrum
so as seguintes reunies: Inicial, Planejamento, Apresentao,
Retrospectiva e Reunio Diria.
9.2.1. A Reunio Inicial

No inicio do projeto necessrio fazer o levantamento de
requisitos do produto a ser desenvolvido. No caso dos processos
Embora o Scrum tenha
sido criado para equipes
pequenas, existem relatos
de projetos com grandes
equipes utilizando essa
metodologia. Existe o
conceito de Scrum de
Scrum aplicado
justamente nesse caso!
86
geis, isso feito em uma srie de reunies, denominada aqui de
Reunio Inicial. Nela que ocorre a definio das estrias do
produto. Uma estria pode ser vista como sendo a descrio do
cliente sobre uma funcionalidade do produto, descrito em sua prpria
linguagem. Cabe a equipe de desenvolvimento entender esse
linguajar e depois detalhar as atividades necessrias para
implementao da estria.
O conjunto de todas as estrias identificadas nessa reunio
inicial ser usado para compor o Product Backlog, que equivale aos
requisitos do produto, descrito na forma de estrias do usurio. A
definio dessas estrias geralmente feita com a participao de
toda a equipe, juntamente com o Product Owner e, opcionalmente,
outros membros representante dos clientes. Essa reunio
geralmente dura um ou mais dias, com bastante conversa sobre as
estrias do produto. fundamental ressaltar que o mais importante
nesse momento no obter um entendimento detalhado sobre o
produto, mas sim identificar as funes existentes e que devem ser
tratadas a posteriori.
O registro dos dados coletados na reunio um ponto crucial
para o restante do processo. necessrio registrar tudo o que foi
discutido pois cada uma dessas estrias sero utilizadas no decorrer
do projeto. Tambm importante que a equipe tente entender
melhor sobre o produto a ser desenvolvido, para que a reunio
possa ser a mais produtiva possvel. Nesse caso, a equipe deve
estudar e ler materiais relacionados, analisar solues similares pr-
existentes e, acima de tudo, perguntando bastante para os
representantes dos clientes.
Um formato seguido pelo autor deste material para guiar as
perguntas sempre questionar como tudo inicia. Por exemplo, no
levantamento de requisitos para uma soluo para uma cooperativa
foi questionado: o que necessitamos para iniciar os trabalhos da
cooperativa? A resposta foi: inicialmente precisamos cadastrar os
cooperados. Nesse caso foi novamente feita outra pergunta: o que
necessrio para cadastrar um cooperado? A resposta foi uma srie
O levantamento de
requisitos durante o uso
do Scrum acontece
durante todo o projeto,
mas a identificao
desses requisitos,
descrevendo-os de forma
sucinta, acontece na
reunio inicial.
87
de dados relacionada ao cooperado, incluindo informaes
bancrias. Nesse momento, uma nova questo foi formulada? O que
necessrio para cadastrar informaes bancrias? Tudo ento se
repete at que tenhamos chegado a um ponto em que tudo que
existe de dependncia tenha sido esclarecido. Logicamente, isso
dar origem a uma srie de estrias, que devero ser registradas.
Resolvendo todas as questes, podemos partir para o prximo
passo: uma vez tendo cooperados cadastrados, o que mais
necessrio? Mais uma vez, as questes seguem novamente...
Um ponto interessante em cada questo tentar identificar
quem o responsvel pelas aes. Isso normalmente est
relacionado a papis dentro do produto. Papis representam
responsabilidades e no pessoas. Cada estria normalmente possui
um papel associado a sua execuo.
As estrias e os papeis podem ser representados utilizando
diagramas de caso de uso. Essa notao ser abordada com mais
detalhes na disciplina Requisitos de Software. Nesse diagrama, os
papis so representados por bonecos e as funcionalidades
(estrias) so representadas por elipses, chamadas de casos de
uso.


Figura 25: Exemplo de Diagrama de Caso de Uso.

A Figura 25 apresenta um exemplo de um diagrama de caso
de uso. Ele exibe dois papis (regulador e intensivista) e algumas
funes do produto (autorizao de envio para lista de espera,
Diagramas de caso de uso
fornecem uma boa viso
dos grupos de usurios do
sistema e suas
funcionalidades
associadas.
88
controle da lista de espera, controle de internao e cadastro de
solicitao de leito). Essas funcionalidades foram descobertas a
partir de conversas com os usurios do produto. Analisando o
diagrama fcil perceber quais so os papis relacionados a certas
estrias, facilitando assim o entendimento. necessrio ainda
detalhar cada caso de uso e cada um dos atores, para facilitar o
entendimento do contexto por qualquer pessoa que ingresse no
projeto. Um exemplo do detalhamento dos casos de uso
apresentado na Tabela 6. Um exemplo do detalhamento dos papis
(ou atores) apresentado na Tabela 7.
Embora o diagrama de caso de uso seja importante para
obtermos um bom entendimento de alto nvel do produto,
necessrio detalhar um pouco melhor cada estria e registr-la em
um formato adequado para manipulao. Uma planilha eletrnica
um formato que utilizamos com relativo sucesso, mas dependendo
do caso, pode no ser o mais adequado. Assim, aconselhamos a
utilizao de uma planilha contendo todos os dados das estrias,
seguindo o modelo de cartes para registro das estrias, detalhado
a seguir.
O principal resultado da reunio inicial o Product Backlog,
que o conjunto dos requisitos do produto e que retrata todo o
trabalho desejado no projeto. Cada estria deve ter sua prioridade
definida pelo Product Owner e repriorizado em vrios momentos do
processo.

89
Tabela 6: Detalhamento dos Casos de Uso.
Nmero de
ordem
Caso de uso Descrio
1 Autorizao de
envio para lista de
espera
Registro da autorizao da solicitao para constar na lista de
espera por leitos.
2 Controle da Lista
de Espera
Controle da lista de espera por leitos, com registro de evoluo
dos pacientes, alm de registro de entrada ou encaminhamento
em leitos hospitalares e eventual remoo da lista.
3 Controle de
Internaes
Controle das internaes em leitos, com possibilidade registro
de alta, e conseqente liberao do leito, alm de
transferncias para outros leitos.
4 Cadastro de
Solicitao de Leito
Cadastro das solicitaes de leitos para pacientes com
necessidades de internao.

Tabela 7: Detalhamento dos atores.
Nmero
de ordem
Ator Definio
1
Intensivista Mdico plantonista que coordena a UTI no
hospital e faz a solicitao das vagas.
2
Regulador Mdico regulador da Central de Leitos, que
recebe, avalia e gerencia as solicitaes e
eventuais interna.

9.2.2. A Reunio de Planejamento

Na Reunio de Planejamento a equipe seleciona os itens do
Product Backlog com os quais se compromete a concluir dentro do
prazo do Sprint. O Sprint o tempo que a equipe planeja para
produzir uma verso funcional do produto com parte dos itens do
Product Backlog. Um tamanho comum para um Sprint gira entre 2 e
4 semanas, mas isso pode ser diferente, dependendo da situao.
Esse nmero pode ser menor, quando precisamos ter respostas
mais rpidas e para obter dados sobre produtividade, ou maiores,
quando as coisas j esto mais estveis e podemos nos dar o luxo
de adiar a entrega para o cliente para termos mais itens
desenvolvidos.
Definido o tamanho do Sprint, hora de calcular a fora de
trabalho que a equipe poder cumprir. Uma forma simples de
calcular multiplicar a soma das quantidades de horas dirias
dedicadas ao projeto por parte da equipe, pela quantidade de dias
A reunio de planejamento
a cerimnia mais
importante do Scrum e
deve ser realizada com
muito cuidado.
90
teis do Sprint. Esse a fora de trabalho bruta. Normalmente
utiliza-se um fator de ajuste para encontrarmos a fora de trabalho
lquida. O fator de ajuste corresponde ao percentual de tempo
produtivo efetivamente utilizado para computar carga de trabalho da
equipe. Colaboradores que trabalham 8h/dia, dificilmente passam 8h
realizando tarefas diretamente relacionadas ao desenvolvimento.
Existe tempo para ler e-mails, conversar com colegas, tomar caf, ir
ao banheiro, etc... Um fator de ajuste muito comum usar 75%, mas
esse nmero depende de vrias condies que devem ser
analisadas.
Um ponto importante na definio da dedicao da equipe
nunca considerar o Scrum Master nem o Product Owner (caso esse
seja um membro da equipe agindo como um cliente) dedicados
integralmente s tarefas de desenvolvimento. Assim, um Scrum
Master que trabalhe 8h/dia certamente poder se dedicar apenas
4h/dia para agir como desenvolvedor. O restante das horas deve ser
gasto com as tarefas de acompanhamento do processo e de auxlio
equipe.

Figura 26: Clculo da fora de trabalho de uma equipe.

A Figura 26 exibe o detalhamento do clculo da fora de
trabalho de uma equipe. Existem cinco colaboradores no projeto,
com sua dedicao diria expressas na figura. Na coluna Total
feito o clculo das horas disponveis durante o Sprint, levando em
necessria muita
prudncia para definio
da dedicao dos
colaboradores ao projeto,
pois isso pode gerar
grandes problemas no
Sprint. Um fator comum
superestimar a
participao dos
membros, esquecendo-se
de outras tarefas
existentes!
91
considerao a quantidade de dias e o fator de ajuste. O valor Total
do Sprint representa a fora de trabalho para essa equipe no Sprint.
Com o clculo da fora de trabalho possvel elaborar o
grfico de acompanhamento, tambm conhecido como Burndown.
Esse grfico nos ajuda a acompanhar visualmente o andamento do
projeto, facilitando a identificao visual de atrasos ou de
adiantamentos. Para sua criao, basta criar uma reta que inicia na
quantidade de horas alocadas para o Sprint e que toca em zero no
ltimo dia do Sprint. A Figura 27 exibe o grfico para os clculos que
fizemos anteriormente. Em breve, na cerimnia denominada
acompanhamento dirio, descrevemos como o grfico dever ser
utilizado.

Figura 27: Grfico de acompanhmento.

O prximo passo selecionar as estrias que faro parte do
Sprint. Elas comporo o que denominamos Sprint Backlog, ou os
requisitos do Sprint. Para que possamos inserir uma estria no
Sprint teremos que conversar sobre ela e tentar descobrir todas as
atividades associadas ao seu desenvolvimento. Observe que uma
estria pode desencadear vrias atividades ou uma apenas. Tudo
depende da situao.
Grfico de Acompanhamento
0
10
20
30
40
50
60
70
80
90
100
110
120
130
140
150
160
170
180
0 1 2 3 4 5 6 7 8 9 10
Dias do Sprint
h
92
Cada estria a ser inserida no Sprint deve ser representada
por um carto, com o formato exibido na Figura 28. Ele possui
diversos compartimentos, cada um com um significado especfico:
ID: identificador da tarefa;
Nome: descrio resumida da tarefa para fcil
identificao;
Descrio: texto simples e objetivo descrevendo a
tarefa com mais detalhes;
Como verificar: indicao de como deve ser feita a
verificao dessa tarefa, quando a mesma estiver
concluda;
Tempo estimado: tempo especificado pela equipe para
realizao da tarefa;
Tempo real: tempo efetivamente utilizado para
realizao da tarefa;
Responsvel: colaborador encarregado de realizar a
tarefa.


Figura 28: Exemplo de carto descrevendo uma atividade.
93

Para o clculo do tempo estimado a maioria das equipes que
usa Scrum utiliza o Jogo do Planejamento. Nesse jogo, cada
membro da equipe deve opinar com uma estimativa de tempo para
uma atividade. Essa estimativa deve ser feita a partir do lanamento
de cartas com o valor estimado. Isso ocorre dessa maneira para
tentar no influenciar os outros membros da equipe em suas
estimativas. De preferncia, as cartas devem ser atiradas viradas, de
forma que apenas depois que todos as joguem que possamos vira-
las para ento analisar os valores estimados. A Figura 29 exibe
algumas cartas utilizadas durante o Jogo do Planejamento. Pode-se
considerar a mdia dos valores obtidos, o que bastante comum, ou
descartar alguns valores para esse clculo (maior e menor, por
exemplo). O mais importante estabelecer parmetros de aceitao,
impedindo, por exemplo que estimativas muito diferentes possam
acontecer. Por conta disso existem algumas definies para as
cartas que merecem ateno:
Um ? indica que mais explicaes so necessrias;
Um 0 indica algo to pequeno que no merece
estimar;
Uma xcara indica necessidade de tempo pra pensar e
hora para o caf...
Tarefas acima de 16h merecem ser divididas, pois em caso
contrrio podem gerar problemas no acompanhamento, por serem
grandes demais e necessitarem de vrios dias para se descobrir que
ela est atrasada! Estimativas muito diferentes merecem explicaes

importante que todos
faam suas estimativas
sem conhecer as
estimativas dos outros
membros do grupo, para
evitar interferncias nas
opinies. Mas
fundamental conversar
quando grandes
diferenas so
registradas!
94

Figura 29: Exemplos de cartas para o jogo do planejamento.

Assim, para que possamos descobrir que itens devem entrar
em um Sprint devemos analisar as prioridades dos itens no Product
Backlog e selecionar aquele com maior prioridade. Em seguida
devemos conversar bastante sobre a estria, a ponto de
descobrirmos as tarefas associadas, para ento iniciar a estimativa
das tarefas. Cada vez que uma tarefa ingressar no Sprint devemos
calcular quanto ainda temos que horas disponveis, para saber se
mais tarefas podem ser introduzidas no Sprint.
O Tempo real, presente nos cartes, deve ser preenchido
com o tempo realmente gasto para concluso da tarefa,
independente do tempo estimado. A partir do confrontamento entre
o tempo estimado e o tempo real que poderemos apurar nossas
estimativas e assim chegarmos em um ponto onde o erro possa ser
considerado desprezvel.
A principio, os responsveis pelas tarefas no devem ser
definidos: cada um escolhe, dentre as tarefas do Sprint, aquilo que
for mais interessante em seu ponto de vista, sempre respeitando as
prioridades envolvidas.
Embora o campo Como verificar parea dispensvel,
quando existem muitas tarefas a verificar, podemos perder o foco no
que importante. Esse campo ajuda a sempre mantermos o foco em
como a tarefa deve ser verificada, garantindo assim que ela foi
realmente concretizada.
Outro item importante a ser definido durante o planejamento
a Definio de Feito (DoD). Todo projeto deve ter uma definio
95
clara sobre o que considerado feito! Para uma tarefa de
modelagem, por exemplo, poderamos considerar uma tarefa
efetivamente concluda apenas se existe:
Diagrama representando a modelagem feita na
ferramenta de modelagem definida no projeto;
Diagrama contido em um repositrio do projeto;
Reviso em conjunto com o Scrum Mster.
Um outro ponto prescrito pelo Scrum so as reunies dirias,
que abordaremos a seguir. Durante o planejamento importante a
definio do local e horrio dessas reunies.
Por fim, um quadro com as informaes do Sprint precisa ser
criado. Um exemplo desse quadro exibido na Figura 30. O quadro
deve ter as seguintes divises para tarefas: No iniciadas, Em
execuo, Concludas e Verificadas. Tarefas concludas so aquelas
em que seus executores acreditam ter finalizado todo o trabalho
associado. No entanto, elas podem no estar totalmente finalizadas,
por conta do esquecimento de algum item a ser feito, e por conta
disso no recebem o status de verificadas, devendo retornar para
em execuo. As possveis mudanas de estados permitidas so
exibidas no diagrama de estados contido na Figura 31. Nessa figura
podemos notar que uma tarefa em execuo pode ser considerada
concluda pelo seu responsvel, mas ela pode retornar para em
execuo, caso o Scrum Mster no a considere concluda durante
a verificao que sempre exigida nesses casos.

Sem a definio de feito
clara e precisa comum
que as tarefas entrem e
saiam da coluna
concluda, retornando para
em execuo, por diversas
vezes, sem que esteja
efetivamente terminada.
96

Figura 30: Exemplo da organizao do quadro do Sprint.


Figura 31: Mudanas permitidas no quadro do Sprint.

De um modo geral, o quadro do Sprint algo fundamental
para o processo, devendo conter todos os itens que facilitem a
comunicao com a equipe e o restante da organizao, sendo elas:
rea para Objetivo do Sprint;
rea para o Grfico de Acompanhamento;
rea para especificar a equipe;
rea para detalhar a data de incio e fim do sprint;
rea para especificar dia da apresentao dos
resultados;
rea para especificar local e horrio das reunies
dirias;
rea para especificar o dia da retrospectiva do Sprint.
importante manter o
quadro do projeto com
todas as definies
registradas aqui!
97

9.2.3. A Reunio Diria

A Reunio Diria uma prtica feita com toda a Equipe, o
ScrumMaster e o Product Owner, com durao de no mximo 15
minutos, apenas para uma avaliao das aes do dia anterior e o
planejamento do dia. O objetivo principal da reunio consiste em
cada membro responder as seguintes perguntas: O que voc fez de
ontem pra hoje? O que far de hoje at amanh? Existe algum
impedimento?
Na reunio no se resolve problemas: eles devem apenas ser
identificados e os envolvidos em sua resoluo devem se reunir
posteriormente para tentar chegar a uma possvel resoluo.
Os impedimentos identificados na reunio devem ser
registrados, assim como os itens no planejados. Todos esses
elementos precisam ser registrados para acompanhamento.
importante garantir que todos falem, sob a superviso do Scrum
Master.
9.2.4. Acompanhamento do Projeto

O Scrum Mster possui diversas tarefas no controle dirio do
projeto, alm da reunio diria:
Verificar tarefas concludas
Atualizar grfico de acompanhamento
Resolver impedimentos
Atuar quando houver desvio no planejamento
Para a verificao das tarefas concludas, normalmente
aconselhado a presena do Scrum Master e do Product Owner. O
que deve ser feito a utilizao da definio de como verificar
existente no carto, para analisar se realmente o item est
concludo. Se algo discordar do que foi acertado para o projeto, isso
deve ser indicado ao responsvel para correo e efetiva concluso
do item. Conforme ser visto na disciplina de Qualidade de Software,
A reunio diria TEM que
ser rpida, caso contrrio,
perder sua efetividade!
98
importante ter muito cuidado com os testes, para as tarefas que
envolvem implementao. Tambm necessrio incluir a anlise do
cdigo fonte, para evitar surpresas futuras.
A atualizao do grfico de acompanhamento deve seguir a
seguinte diretriz: para cada tarefa concluda e verificada, baixar o
nmero correspondente estimativa da tarefa no grfico. Muito
importante: baixar a estimativa e no o tempo efetivamente gasto!
Essa ao no prov uma informao visual de fcil interpretao e
de grande valia para qualquer gerente de projeto. Talvez seja aquilo
que mais chamativo no Scrum.
Para exemplificar, se existe uma tarefa estimada em 8h
dentro do backlog do Sprint, mesmo que ela tenha sido feita em 12h,
devemos baixar no grfico de acompanhamento apenas 8h quando
ela tiver sido efetivamente concluda e verificada.
Sempre que houver uma diferena muito grande no previsto e
no realizado o Scrum Mster deve tentar identificar as causas e, se
possvel, atuar para tentar resolver o problema associado. Da
mesma forma, toda vez que um impedimento for registrado
necessrio procurar mecanismo para resolv-los, caso contrrio,
todo o projeto poder ser comprometido.

9.2.5. Apresentao do Sprint

Ao final de um Sprint, o Scrum recomenda que seja feita a
apresentao dos resultados. Essa apresentao tipicamente se
resume a demonstrao de novas funcionalidades do produto ou da
sua arquitetura, nos casos de implementao. Ela informal, sem a
necessidade de muita preparao e sem slides. Toda a equipe deve
participar, assim como outros participantes. Essa reunio uma
forma de forar o comprometimento de todos com o trabalho
realizado e uma forma de estimular a obteno de resultados
efetivos, uma vez que tudo o que foi feito dever ser apresentado.
99
9.2.6. Retrospectiva

Durante um Sprint, necessrio observar o que funciona e o
que no funciona. Na retrospectiva, tudo o que aconteceu e merece
algum registro deve ser discutido por todos para que possamos ter
melhores resultados em Sprints futuros, levando em considerao as
experincias passadas. Essa reunio tipicamente rpida, durando
cerca de uma hora, ao final de cada Sprint, com todos os envolvidos
no projeto. A equipe tenta responder a trs questes nessa reunio:
O que voc achou muito bom no Sprint e que deveria
continuar sendo feito;
O que voc achou muito ruim e no deveria mais ser
feito (ou mudado);
O que no est sendo feito, mas deveria iniciar.
Um formato indicado para conduzir tal reunio solicitar a
cada participante que responda s questes, respondendo com at
trs alternativas cada questo, com cada uma das respostas em um
carto diferente. Nesse caso, se houver trs respostas para cada
pergunta, dever haver nove cartes para um participante. Em
seguida, para cada questo devem ser agrupadas as respostas
similares, de forma a identificarmos as respostas mais comuns. Em
cima dessa identificao que registraremos o que foi mais
consensual para cada uma das trs questes. O Scrum Mster deve
ficar atento a esses itens e garantir que eles sero levados em
considerao no prximo Sprint.
9.3. Finalizao

Neste captulo apresentamos as recomendaes de um
processo de software muito utilizado mundialmente, o Scrum.
Explicamos as diversas cerimnias associadas ao seu uso, de forma
a tentar deixar claro os passos a serem executados para seu uso em
um projeto. No prximo captulo, para tentar clarificar mais ainda o
uso desse processo, apresentamos como utilizar o Scrum para guiar
uma atividade simples.
100
De forma geral, as atividades para se utilizar o Scrum em um
projeto, so as seguintes:
1. Obter a lista do que fazer (product backlog).
2. Priorizar os elementos da lista.
3. Definir o tamanho do Sprint.
4. Calcular a fora de trabalho para o Sprint.
5. Criar o grfico de acompanhamento.
6. Estimar o tamanho das tarefas a comporem o Sprint.
7. Registrar as tarefas utilizando os cartes.
8. Organizar o quadro do projeto, contendo todos os
dados identificados neste captulo.
9. Acompanhar o decorrer do projeto, realizando reunies
dirias, atualizando o grfico de acompanhamento e
verificando as tarefas terminadas, confrontando com a
definio de feito e a forma descrita sobre como
verificar a tarefa.
10. Realizar uma apresentao dos resultados do Sprint.
11. Realizar uma retrospectiva do Sprint.
9.4. Exerccios

1. Qual a origem do Scrum?
2. Quais so os papis relacionados ao uso do Scrum? Detalhe as
responsabilidade de cada um desses papis dentro do processo.
3. Qual o objetivo da Reunio Inicial no Scrum? Qual o principal
artefato gerado?
4. O que um Sprint?
5. Como podemos definir a fora de trabalho para um Sprint no
Scrum? Que variveis podem influenciar nesse clculo?
6. Como sabemos quantas estrias (ou tarefas) podem ser
includas em um Sprint?
7. Quais informaes precisam estar associadas a uma estria (ou
tarefa) registrada em um Sprint?
101
8. O Scrum prescreve a organizao de um Sprint utilizando um
quadro. O que deve ter nesse quadro?
9. Como criado o grfico de acompanhamento e como devemos
atualiz-lo diariamente?
10. Quais so as divises do quadro de tarefas e quais as possveis
transies entre essas divises?
11. Quais so as perguntas bsicas durante as reunies dirias?
12. Quais so as tarefas rotineiras do Scrum Mster durante o dia a
dia dos projetos?
13. O que deve ser feito na reunio de retrospectiva do Sprint? Como
isso pode ser guiado?


102
UNIDADE III
UM EXEMPLO DE UM PROCESSO DE
SOFTWARE

10. Aplicando o SCRUM

Neste captulo apresentamos um exemplo do uso do Scrum
para o desenvolvimento de um livro sobre Introduo Engenharia
de Software. Como o exemplo no est relacionado ao
desenvolvimento de um software e no envolve uma equipe, e sim
um nico executor das tarefas, certamente no poderemos utilizar
todas as prescries do Scrum, uma vez que boa parte delas no
faz sentido quando o desenvolvedor o nico membro atuante no
projeto. No entanto, esse exemplo servir para mostrar a dinmica
maior do processo e o controle que ele pode nos d durante o
desenvolvimento de qualquer tarefa.
10.1. O Exemplo

Conforme mencionado anteriormente, utilizaremos como
exemplo o desenvolvimento de um livro introdutrio sobre
Engenharia de Software.
Depois de alguns momentos de reflexo fizemos a construo
do Backlog desse projeto, que seria composto basicamente pelas
seguintes tarefas exibidas na Tabela 8. Nela as prioridades definidas
para as atividades j encontram-se especificadas.

Tabela 8: Product Backlog para o exemplo considerado.
ID Nome Prioridade
1
Estudar conceitos bsicos, processos e ciclo
de vida 80
Qualquer trabalho pode
ser controlado com auxlio
do Scrum! Vrias equipes
de empresas, que no
trabalham com
desenvolvimento de
software, utilizam Scrum
para controlar suas
atividades.
103
2 Escrever captulo introdutrio 60
3 Escrever captulo sobre processos 60
4
Estudar as disciplinas da Engenharia de
Software 50
5
Escrever captulos sobre as principais
disciplinas 40
6 Estudar a metodologia Scrum 30
7 Escrever captulo sobre o Scrum 20

Iremos utilizar Sprints de duas semanas (dez dias teis) para
acompanhamento das tarefas. Com essa definio j podemos criar
nosso grfico de acompanhamento, conforme exibido na Figura 32.
Podemos notar na Figura a definio da carga de trabalho diria,
definida como 1,2h, alm do tamanho do Sprint (10 dias) e o fator de
ajuste considerado (75%). Com isso chegou-se a uma carga de
trabalho do Sprint de 9h.


Figura 32: Dados do Sprint e Grfico de Acompanhamento.

Antes de comear as tarefas importante definir como
verific-las, para que possamos saber exatamente quando
poderemos considerar algo concludo, uma vez que no teremos a
104
ajuda de outras pessoas nessa empreitada, por se tratar de um
trabalho individual. Isso tem haver no somente com a definio dos
cartes, que precisam ter essa informao, como est relacionado
tambm definio de feito associado ao projeto. Um exemplo para
a definio de feito associada s tarefas existentes no Backlog
poderia ser:
Para tarefas relativas a estudos: breve resumo do item
estudado, com detalhamento das referncias utilizadas.
Para tarefas relativas escrita de texto: texto escrito,
formatado conforme exigido, existncia de bibliografia e
exerccios relacionados.
O prximo passo a definio da estimativa de tempo para a
realizao das tarefas. Normalmente encontramos um erro grande
nas tarefas iniciais de um projeto, mas medida que o tempo
prossegue conseguimos cada vez mais nos aproximarmos do tempo
efetivamente gasto. Fizemos a estimativa de todas as tarefas, no
intuito de agilizarmos o processo. Observe que essas estimativas
podem ser alteradas, desde que a tarefa com a estimativa a ser
alterada no se encontra no Sprint em execuo. As tarefas e suas
estimativas so apresentadas na Tabela 9.

Tabela 9: Tarefas com estimativa de execuo.
ID Nome Prioridade
Tempo
Estimado
1
Estudar conceitos bsicos, procesos e ciclo de
vida 80 4
2 Escrever captulo introdutrio 60 4
3 Escrever captulo sobre processos 60 6
4
Estudar as disciplinas da Engenharia de
Software 50 8
5
Escrever captulos sobre as principais
disciplinas 40 4
6 Estudar a metodologia Scrum 30 4
7 Escrever captulo sobre o Scrum 20 4

Com base em nossa carga de trabalho, de apenas 9h, e
analisando o Backlog, sempre atento s prioridades existentes e
estimativas definidas, podemos notar que apenas as tarefas 1 e 2
105
podem ser includas no Sprint inicial, ainda assim deixando uma
lacuna de 1h em aberto. Resolvemos ento iniciar o Sprint com
apenas essas duas tarefas.
Grfico de Acompanhamento
0
1
2
3
4
5
6
7
8
9
10
0 1 2 3 4 5 6 7 8 9 10
Dias do Sprint
h

Figura 33: Grfico de acompanhamento aps a primeira semana de
tabalho.

Na primeira semana de trabalho no conseguimos finalizar
nenhuma das tarefas, o que nos gerou um grfico de
acompanhamento conforme exibido na Figura 33. Observe que
analisando o grfico podemos facilmente perceber que estamos
atrasados em relao ao que foi previsto nas estimativas de
execuo das tarefas. A linha de acompanhamento acima da ideal
indica atraso, assim como a linha abaixo indica um adiantamento em
relao ao previsto.
Ao final de duas semanas e finalizado o Sprint, obtivemos o
grfico exibido na Figura 34. Observe que apenas uma tarefa foi
finalizada, por conta disso, ao final do Sprint o grfico de
acompanhamento indica que produzimos bem menos que o
estimado.
106
Grfico de Acompanhamento
0
1
2
3
4
5
6
7
8
9
10
0 1 2 3 4 5 6 7 8 9 10
Dias do Sprint
h

Figura 34: Grfico de acompanhamento ao final do Sprint.

A tarefa foi finalizada com apenas 3h de esforo, de acordo
com os registros associados sua execuo, exibidos na Tabela 10.
Fizemos uma breve retrospectiva sobre o que aconteceu e
facilmente identificamos que nossa estimativa no foi o problema
principal: na verdade, o desenvolvedor no conseguiu se dedicar
conforme havia sido planejado.
Tabela 10: Registro dos tempos gastos nas tarefas.
ID Nome Prioridade
Tempo
Estimado
Tempo
Gasto
1
Estudar conceitos bsicos, procesos
e ciclo de vida 80 4 3
2 Escrever captulo introdutrio 60 4

Com base nos dados obtidos na retrospectiva teremos que
realizar um novo planejamento para um novo Sprint e continuar com
a execuo das atividades at que tenhamos finalizado todo o
trabalho.
10.2. Discusso sobre o uso do Scrum

Embora o exemplo apresentado anteriormente seja
relativamente simples e no ligado diretamente ao desenvolvimento
de software, ele ilustra parte do uso do Scrum no controle de uma
atividade. importante ressaltar que o Scrum utilizado hoje nas
mais variadas reas de aplicao, tendo rompido a barreira dos
107
ncleos de tecnologia e se espalhado nos outros setores das
empresas j h algum tempo.
O grfico de acompanhamento uma ferramenta fundamental
para qualquer gerente de projeto, pois informa, de maneira simples e
direta, como est o andamento das tarefas planejadas para um
perodo de tempo.
Por tudo isso que o Scrum ganha muito destaque no cenrio
nacional e representa como a Engenharia de Software pode ajudar
no desenvolvimento de software de qualidade, alm de auxiliar a
organizao de qualquer trabalho baseado em tarefas a serem
executadas.
10.3. Exerccios

1. Utilize o Scrum para guiar um projeto bem simples: a leitura de
um livro. Esse livro poder ser livremente escolhido por voc.
Leia alguns captulos inicialmente, apenas para ter noo da sua
velocidade de leitura de pginas. Em cima disso, planeje as
tarefas (ler os captulos 1, 2, 3, 4, ...), calcule sua fora de
trabalho para o Sprint, defina o tamanho do Sprint, acompanhe
sua execuo, sempre de olho no grfico, conforme exemplo
exibido nesse captulo. Faa um breve relato sobre o uso do
processo para controlar essa atividade.

108
WEBLIOGRAFIA
UNIDADE III
UM EXEMPLO DE UM PROCESSO DE
SOFTWARE




Organizao divulgadora do Scrum mundialmente
http://www.scrumalliance.org/

Empresa com diversos artigos e casos de sucesso no uso de
prticas geis
http://www.mountaingoatsoftware.com/

Vdeos e tutoriais sobre o Scrum
http://www.controlchaos.com/

Stio com um livro disponvel para download
http://www.infoq.com/br/

Srcumming - Ferramenta Educacional para Apoio ao Ensino de
Prticas de SCRUM
http://www.inf.pucrs.br/~rafael/Scrumming/

Manifesto gil
http://agilemanifesto.org/
109
REFERNCIAS BIBLIOGRFICAS
UNIDADE III
UM EXEMPLO DE UM PROCESSO DE
SOFTWARE





HENRIK KNIBERG H., Scrum e XP das Trincheiras: Como fazermos
Scrum, InfoQ, 2007.
HIROTAKA TAKEUCHI, IKUJIRO NONAKA,, The New Product
Development Game, Harvard Business Review, 1986.
KEN SCHWABER, SCRUM Development Process, Burlington, MA,
USA, 1996.
KEN SCHWABER, Agile Project Management with Scrum. Microsoft
Press, 2004.
STANDISH, The Standish Group International, CHAOS
Demographics and Project Resolution, Dennis, MA, USA, 2004.
VINICIUS MANHES TELES, Extremme Programming, Editora
Novatec, 2004.








110
Autor

Possui graduao em Bacharelado em Cincia da Computao pela
Universidade Federal do Piau (1995), mestrado em Cincia da
Computao pela Universidade Federal de Pernambuco (1999) e
doutorado em Cincia da Computao pela Universidade Federal de
Minas Gerais (2006). Atualmente professor da Universidade
Federal do Piau. Tem experincia na rea de Engenharia de
Software, atuando principalmente na automao de testes,
desenvolvimento de software utilizando metodologias geis e
engenharia de software experimental.

Pedro de Alcntara dos Santos Neto
CV. http://lattes.cnpq.br/3452982259415951