Introdução À Engenharia de Software

Universidade Federal do Piau
Centro de Educao Aberta e a Distncia
INTRODUO
ENGENHARIA DE
SOFTWARE
Pedro de Alcntara dos Santos Neto
Ministrio da Educao - MEC
Universidade Aberta do Brasil - UAB
Universidade Federal do Piau - UFPI
Universidade Aberta do Piau - UAPI
Centro de Educao Aberta e a Distncia - CEAD
Introduo Engenharia
de Software

PRESIDENTE DA REPBLICA Dilma Vana Rousseff Linhares
MINISTRIO DA EDUCAO Fernando Haddad
GOVERNADOR DO ESTADO Wilson Nunes Martins
REITOR DA UNIVERSIDADE FEDERAL DO PIAU Luiz de Sousa Santos Jnior
SECRETRIO DE EDUCAO A DISTNCIA DO MEC Carlos Eduardo Bielshowsky
PRESIDENTE DA CAPES Jorge Almeida Guimares
COORDENADOR GERAL DA UNIVERSIDADE ABERTA DO BRASIL Celso Costa
DIRETOR DO CENTRO DE EDUCAO ABERTA E A DISTNCIA DA UFPI Gildsio Guedes Fernandes
COORDENADORES DE CURSOS
ADMINISTRAO Francisco Pereira da Silva Filho
CINCIAS BIOLGICAS Maria da Conceio Prado de Oliveira
FILOSOFIA Zoraida Maria Lopes Feitosa
FSICA Miguel Arcanjo Costa
MATEMTICA Joo Bencio de Melo Neto
PEDAGOGIA Vera Lcia Costa Oliveira
QUMICA Rosa Lima Gomes do Nascimento Pereira da Silva
SISTEMAS DE INFORMAO Luiz Cludio Demes da Mata Sousa
EQUIPE DE DESENVOLVIMENTO CONSELHO EDITORIAL DA EDUFPI

TCNICOS EM ASSUNTOS EDUCACIONAIS Ubirajara Santana Assuno Prof. Dr. Ricardo Alaggio Ribeiro ( Presidente )
Zilda Vieira Chaves Des. Tomaz Gomes Campelo
Djane de Oliveira Brito Prof. Dr. Jos Renato de Arajo Sousa
EDIO Roberto Denes Quaresma Rgo Prof. Dr. Teresinha de Jesus Mesquita Queiroz
PROJETO GRFICO Samuel Falco Silva
Prof. Francisca Maria Soares Mendes
DIAGRAMAO Jos Lus Silva
Prof. Iracildes Maria de Moura F Lima
Luan Matheus dos Santos Santana
Prof. Dr. Joo Renr Ferreira de Carvalho
REVISO Lgia Carvalho de Figueiredo
REVISO GRFICA Maria da Penha Feitosa
S237i Santos Neto, Pedro de Alcntara dos.

Introduo engenharia de software / Pedro de
Alcntara dos Santos Neto. - Teresina: EDUFPI/CEAD,
2013.
92 p.
ISBN
1. Engenharia de Sftware. 2. Software - Desenvolvi-

mento. 3. Software. 4. Educao a Distncia. I. Ttulo.
CDD 004.21
2011. Universidade Federal do Piau - UFPI. Todos os direitos reservados.
A responsabilidade pelo contedo e imagens desta obra do autor. O contedo desta obra foi licenciado temporria e
gratuitamente para utilizao no mbito do Sistema Universidade Aberta do Brasil, atravs da UFPI. O leitor se compromete
a utilizar o contedo desta obra para aprendizado pessoal, sendo que a reproduo e distribuio ficaro limitadas ao mbito
interno dos cursos. A citao desta obra em trabalhos acadmicos e/ou profissionais poder ser feita com indicao da fonte.
A cpia desta obra sem autorizao expressa ou com intuito de lucro constitui crime contra a propriedade intelectual, com
sanses previstas no Cdigo Penal.
proibida a venda ou distribuio deste material.
Os Sistemas de Informao (SI) so produtos de softwares cada vez
mais importantes no dia a dia das pessoas. Tais sistemas so usualmente com-
postos por muitos elementos que operam juntos para recuperar, processar, ar-
mazenar e distribuir informaes, que normalmente so utilizadas 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 se
possa obter altos nveis de qualidade a baixos custos.
Neste livro apresentamos uma introduo Engenharia de Software,
que a rea da computao que aborda a sua construo, 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 os conceitos de
processo e dos modelos de ciclo de vida, os quais 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 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.
UNIDADE 1
09 CONCEITOS BSICOS
Conceitos Bsicos................................................................................11
Introduo...........................................................................................11
Ser que a crise acabou.......................................................................13
O que Engenharia de Software.........................................................15
Problemas no desenvolvimento de software......................................18
Software: Mitos e Realidade................................................................21
Mitos do Gerenciamento.....................................................................21
Mitos do Cliente...................................................................................22
Mitos do Profissional...........................................................................23
Processos de Software.........................................................................24
Modelos de ciclo de vida............................................................ .........26
Codifica-Remenda..................................................................... ..........27
Cascata....................................................................................... .........28
Espiral.......................................................................................... ........29
Incremental................................................................................. ........30
Entrega Evolutiva......................................................................... ........33
Outros modelos de ciclo de vida................................................. ........34
UNIDADE 2
37 AS PRINCIPAIS DISCIPLINAS DA ENGENHARIA DE SOFTWARE
Requisitos...................................................................................... ......39
O Processo Prxis.......................................................................... ......39
O Fluxo de Requisitos................................................................... .......40
Fluxo de anlise...................................................................................45
Fluxo de desenho............................................................. ...................48
Implementao...................................................................................53
Gesto de Projetos..................................................................... .........61
UNIDADE 3
67 EXEMPLO DE UM PROCESSO DE SOFTWARE
Os papeis............................................................................................. 68
As cerimnias...................................................................................... 69
A reunio inicial................................................................................... 70
A reunio de planejamento................................................................. 73
A reunio diria................................................................................... 79
Acompanhamento do projeto............................................................. 79
Apresentao do Sprint....................................................................... 80
Retrospectiva....................................................................................... 80
Aplicando o Scrum............................................................................... 82
O exemplo........................................................................................... 82
Discusso sobre o uso do Scrum......................................................... 86
UNIDADE 01
Conceitos Bsicos
Resumindo
Nesta unidade apresentamos os conceitos bsicos da Engenharia de Software, definindo
os pontos bsicos para o seu entendimento. Apresentamos o evento que deu origem
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, em vez de histrias interessantes e cativantes.
CONCEITOS BSICOS 9
10 unidade 01
CONCEITOS BSICOS
INTRODUO
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 na 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 A crise do software
surgiu devido ao
para o desenvolvimento de sistemas que funcionassem adequadamente ou
amadorismo existente
pudessem ser validados. na conduo
do processo de
desenvolver software.
Em 1968, surgiu
a Engenharia de
Software.
Figura 1: Fotos da NATO Software Engineering Conference.
A NATO Software Engineiring Conference marcou o incio de uma

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, Edsger Dijkstra.
Em 1972, Dijkstra recebeu o Prmio Turing (Turing Award), que
CONCEITOS BSICOS 11
dado anualmente pela Association for Computing Machinery (ACM), para
uma pessoa selecionada pelas contribuies de natureza tcnica feitas para
a comunidade da computao. Seu discurso no 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.
Dijkstra um
personagem ilustre Mas, o que realmente seria a crise do software? Podemos resumir
da computao, com
a crise imaturidade no desenvolvimento de software, causando diversos
diversas contribuies
em diversas reas. problemas, como por exemplo:
1. Projetos estourando o oramento;
2. Projetos estourando o prazo;
3. Software de baixa qualidade;
4. Software muitas vezes no atendendo aos requisitos;
5. Projetos no gerenciveis e cdigo de difcil manuteno.
Figura 2: Exemplo de um quadro da situao na poca da crise do software.
12 unidade 01
A Figura 2 exibe um quadro da situao relacionada ao
desenvolvimento de software na 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 e 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 muito difcil. Dados do STANDISH
GROUP, em 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 que
o previsto.
Considerando todos os projetos que foram entregues, alm do prazo e Ainda hoje diversos
com custo maior, na mdia, apenas 61% das funcionalidades originais foram projetos de
desenvolvimento de
includas. Mesmo os projetos cuja entrega feita respeitando os limites de
software fracassam.
prazos e custos 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.
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.
CONCEITOS BSICOS 13
Figura 3: Dificuldades durante o desenvolvimento de software.
Ainda hoje diversos
A Figura 3 apresenta uma ilustrao muito conhecida na rea de
projetos de
desenvolvimento de Engenharia de Software. Ela apresenta um grande problema relacionado
software falta de entendimento entre os grupos que fazem parte de um projeto. O
fracassam. 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 e que bastante diferente do que ele relatou que necessitava. Mais
adiante, quando 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 frequncia, os processos, mtodos e ferramentas existentes
14 unidade 01
auxiliam muito o desenvolvimento. Uma vez aplicados por pessoas com os
conhecimentos adequados, podemos ter certeza do sucesso em um projeto.
Por conta disso, 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.
Um grande problema
a ser superado a
falha na comunicao
O que Engenharia de Software?
entre as equipes.
J comentamos sobre as origens da Engenharia de Software, mas Assim como na
at agora no fizemos uma definio precisa do que seja exatamente isso. construo civil,
Nesta seo faremos isso. Mas antes da definio, vamos fazer uma analogia muitas empresas
estouram custos
muito interessante: voc sabe como funciona o processo de fabricao de um
e prazos, mesmo
carro? tendo mtodos
e tcnicas bem
estabelecidos. No
desenvolvimento de
software a situao
a mesma: aqueles que
utilizam os princpios
corretamente tm
grandes chances de
sucesso.
Figura 4: Passos para desenvolvimento de um carro
A Figura 4 apresenta os passos para desenvolvimento de um carro.

Sua construo inicia a partir do momento que se tem a ideia 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 como
porta-malas com capacidade de 500l, motor 1.6, cmbio automtico, etc.
CONCEITOS BSICOS 15
Com a identificao dos requisitos possvel iniciar a montagem de
um prottipo, avaliando diversos pontos que necessitam de esclarecimento
antes da construo efetiva do carro. Essa prototipao poder 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 iniciar o 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
atendido 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 dessa
forma.
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 item, uma nova verificao necessria aps
sua integrao com os 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 porque o
16 unidade 01
processo de fabricao de um carro tem tudo a ver 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 (testes 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

A construo de um
de Software, dentre elas destacamos:
carro e a construo
O estabelecimento e uso de slidos princpios de engenharia para de um software so
que se possa obter economicamente um software que seja confivel e que projetos similares, mas
que exigem diferentes
funcione eficientemente em mquinas reais. (PETER, 1969)
habilidades na sua
A aplicao prtica do conhecimento cientfico para o projeto e a conduo e execuo.
construo de programas computacionais e a documentao necessria
sua operao e manuteno. (BOEHM, 1976)
Conjunto de mtodos, tcnicas e ferramentas necessrias produo

de software de qualidade para todas as etapas do ciclo de vida do produto.
(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
CONCEITOS BSICOS 17
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
necessrios. Por conta disso, boa parte desses projetos fracassa. Na prxima
seo vamos discutir alguns dos aspectos que fazem isso acontecer.
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 maioria dos casos. A
crise continua em muitos locais, no mais por ausncia de mtodos, tcnicas
e ferramentas, mas pela falta do seu uso!
Processos Pessoas
Tecnologia
Figura 5: Trip da Engenharia de Software.
A Figura 5 apresenta o trip no qual a Engenharia de Software

baseada em 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 grandes chances de termos
problemas relacionados falta de controle ou desorganizao, caso no
tenhamos um processo que discipline as tarefas das pessoas.
18 unidade 01
Hardware
Hardware Vias
Vias de
de comunicao
comunicao
Bases
Bases de
de dados
dados Software
Software
Figura 6: Componentes de um sistema.
Um conceito que muitas vezes causa confuso o de sistema, que

muito se confunde com o 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 preciso um
sejam manipuladas adequadamente e a documentao necessria para um equilbrio entre
melhor entendimento da sua operao e uso. pessoas, processos
e tecnologias
Entretanto, no contexto da Engenharia de Software, o software deve para o sucesso
ser visto como um produto a ser vendido. importante dar esta nfase, em um projeto de
diferenciando os programas que so concebidos num contexto mais restrito, desenvolvimento de
software.
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, 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
CONCEITOS BSICOS 19
tero capacidade) de detectar e corrigir os eventuais erros de execuo.
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 consequente custo associado ao desenvolvimento de um produto sero
O termo bug est
muito superiores.
associado ao conceito
de falha. Bug signifca Um sistema bem mais que o software. Na verdade, o sistema o
inseto em Ingls.
conjunto de elementos, coordenados entre si e que funcionam como uma
Diz-se que o termo
foi criado por Thomas estrutura organizada. Embora o software seja uma parte importante de um
Edson quando sistema, ele no o nico. Se no existir o hardware para execuo do software,
um inseto causou de nada servir. Da mesma forma, necessrio existir base de dados, uma
problemas de leitura vez que praticamente todos os sistemas com algum tipo de utilidade devem
em seu fongrafo em
armazenar dados. Atualmente, com o advento da Internet, dificilmente um
1878, mas pode ser
que o termo seja mais sistema seja til se no tiver certos mecanismos de comunicao associados.
antigo. A inveno Tudo isso junto forma o sistema. Por diversas vezes tendemos a utilizar
do termo atribuda software e sistema como algo similar, mas importante ressaltarmos suas
erroneamente a
diferenas, de forma a deixar claro o que representa cada um desses termos.
Grace Hopper, que
publicou em 1945 Os produtos de software desenvolvidos utilizando a Engenharia de
que a causa do Software sempre esto envolvidos em algum processo de negcio, seja
mau funcionamento
ele simples ou complexo. Assim, fundamental entender esse processo
no Mark II (um
dos primeiros de negcio para que seja possvel informatiz-lo. Embora isso seja bvio,
computadores) seria em muitas ocasies isso simplesmente ignorado. O desenvolvimento
um inseto preso nos de software muitas vezes acontece sem sabermos o que deve ser feito.
contatos de um rel.
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: Qual
o custo de uma construo de 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. Tudo depende dos requisitos relacionados a 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
20 unidade 01
o que deveriam fazer porque 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 o 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.
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 (2002).
Diferentes dos antigos mitos, que so interessantes histrias e frequentemente
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, cabe a todos ns conhec-los, para tentar
evit-los em locais que isso ainda esteja acontecendo.
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 em relao a todos os problemas de desenvolvimento
que podero aparecer no percurso.
CONCEITOS BSICOS 21
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 saber utiliz-las
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 isso, sero utilizados
elementos que esto envolvidos diretamente no desenvolvimento, o que vai
consequentemente implicar em maiores atrasos no cronograma.
Mitos do cliente
Mito 4. Uma descrio breve e geral dos requisitos do software o suficiente

para iniciar o seu projeto. Mais 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 para depois pode
simplesmente no acontecer, a no ser em casos previstos pelos processos
geis em que os clientes esto sempre presentes 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 isso 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

que a maioria dos produtos manufaturados). Entretanto, no existe software,
por mais flexvel, que suporte alteraes de requisitos significativos sem um
22 unidade 01
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.
CUSTO 60~100X
1.5~6X
1X
DEFINIO DESENVOLVIMENTO DENOMINAO
Figura 7: Influncia das alteraes de requisitos no custo de um sistema.
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 disso.

Segundo dados obtidos a partir de experincias anteriores, ilustrados no livro
de Roger Pressman (2002), 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 da qualidade do

software deve fazer parte de todas as etapas do desenvolvimento. O teste,
por exemplo, pode iniciar antes de o 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.
Realidade 8. O programa em funcionamento um dos 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!
CONCEITOS BSICOS 23
Exerccios de fixao
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. Faa 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.
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:
1. A concepo, na qual o produto idealizado, a partir da percepo de uma

necessidade;
24 unidade 01
2. O desenvolvimento, a partir da identificao dos requisitos e sua
transformao em itens a serem entregues ao cliente;
3. A operao, quando o produto instalado para ser utilizado em algum

processo de negcio, sujeita a manuteno, sempre que necessrio;
4. A retirada, quando o produto tem sua vida til finalizada.
No ciclo de vida de um software, a codificao 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 de que esse guia depende do modelo de ciclo de vida utilizado. Existem
vrios modelos e, dependendo deles, 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 Filho (2003), um processo deve ter uma documentao

que o descreva, 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
CONCEITOS BSICOS 25
o caso dos Processos geis, o qual vero mais adiante ou completamente
detalhado, 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.
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
O termo modelo
de ciclo de vida ciclo de vida pode ser apropriado para um projeto, mas no ser apropriado
utilizado para para outro. necessrio entender bem os conceitos relacionados para que
descrever um as escolhas feitas sejam baseadas em conhecimento e no no acaso. Na
grupo de atividades prxima seo iremos detalhar os modelos de ciclo de vida existentes, que
relacionado ao
muitas vezes so tratados como paradigmas de engenharia de software.
desenvolvimento
de software e as Neste trabalho vamos utilizar o termo modelo de ciclo de vida ao invs de
formas como elas paradigma, por acharmos que ele mais apropriado.
se relacionam. Para
cada modelo de
ciclo de vida existe Modelos de ciclo de vida
um relacionamento
diferente entre Conforme j comentado, ciclo de vida pode ser resumido como sendo
as atividades, todas as atividades relacionadas a um software, desde a concepo de suas
determinando formas
ideias at a descontinuidade do produto. Existem diversos modelos de ciclo
diferentes de se
conduzir o processo de vida, com caractersticas diferentes. Nesta seo iremos apresentar os
de construo do principais modelos de ciclo de vida.
produto.
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 que sero um pouco mais detalhados
nos captulos posteriores:
1. Requisitos: obteno do enunciado completo, claro e preciso dos desejos,

necessidades, expectativas e restries dos clientes em relao ao produto
a ser desenvolvido.
2. 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.
26 unidade 01
3. Desenho (ou projeto): definio de uma estrutura implementvel para um
produto que atenda aos requisitos especificados.
4. Implementao: codificao das partes que compem o software, definidas

no desenho, utilizando as tecnologias selecionadas.
5. 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.
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
interao.
Figura 8: Modelo de ciclo de vida codifica-remenda.
CONCEITOS BSICOS 27
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
O modelo cascata tema a ser abordado e trabalhar para gerar algo como resultado. Por outro
ainda o mais lado, um modelo de alto risco, praticamente impossvel de se gerenciar,
comum, pela falta tornando-se impossvel estabelecer qualquer estimativa de custo e prazo.
de profissionais
habilitados para o
desenvolvimento de
software. De forma Cascata
similar, existem O modelo em cascata, tambm conhecido como modelo
muito mais obras sequencial linear, sugere que os principais subprocessos relacionados ao
sendo tocadas
desenvolvimento de software sejam executados em sequncia, conforme
por profissionais
sem qualquer apresentado na Figura 9.
formao tcnica
que obras tocadas
por engenheiros. O
resultado disso que
dificilmente uma obra
sem um engenheiro
possuir custo e prazo
conhecidos!
Figura 9: 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
28 unidade 01
preterido por outros modelos. Dentre essas falhas, destacam-se as relatadas
por Pressman (2002):
1. Projetos reais raramente seguem o fluxo sequencial, conforme sugerido

pelo modelo. Isso pode causar grandes problemas quando temos mudanas
em um projeto em andamento;
2. Em geral, difcil para os clientes identificarem todos os requisitos

explicitamente. Esse modelo exige isso e tem dificuldade em acomodar a
incerteza natural que existe em grande parte dos projetos;
3. 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.
Espiral
Um modelo bem diferente do apresentado anteriormente (cascata)

O modelo em cascata
o modelo em espiral. Esse modelo foi proposto originalmente por Barry , em teoria, uma
Boehm. A ideia bsica desenvolver um produto a partir de pequenas maravilha. Na prtica,
verses incrementais, que podem iniciar com um modelo em papel e evoluir rgido e burocrtico,
tendo sido
at verses do sistema completamente funcionais.
considerado invivel
pelas organizaes
que o utilizam.
Ativao Anlise
Operao Desenvolvimento
Figura 10: 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
CONCEITOS BSICOS 29
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.
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
A ideia bsica por e identificar requisitos com mais propriedade. Isso facilita o uso desse tipo de
trs do modelo em
modelo de ciclo de vida. No entanto, como apenas uma parte do produto
espiral : dividir para
conquistar. Ao invs considerada, possvel que uma deciso tomada seja incompatvel com uma
de querer resolver nova parte sendo desenvolvida. Isso acontece porque a tomada de decises
todos os problemas feita apenas com o conhecimento do produto que existe at o momento.
de uma vez,
O ideal seria que todo o produto j fosse conhecido, o que nos remete ao
interessante resolver
parte deles e ento modelo em cascata novamente. Esse ponto justamente o problema do
partir para o restante. modelo em espiral: sua dificuldade de gerir, para que tenhamos estimativas
em um projeto que seja previsvel e confivel.
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
cada vez mais requisitos e que so efetivamente entregues aos clientes.
30 unidade 01
Embora os processos
geis prescrevam
pouca burocracia, eles
prescrevem alguma
burocracia. No segui-
las pode significar
anarquia total no
desenvolvimento.
Existem muitas
Figura 11: Modelo de ciclo de vida incremental (prototipagem evolutiva) organizaes que
dizem seguir os
No modelo incremental, um projeto dividido em vrias interaes, preceitos geis,
apenas porque no
os quais que so divises do produto que sero consideradas durante a
seguem nada, o que
construo. Escolhe-se uma dessas interaes para iniciar o desenvolvimento, um completo absurdo
comeando pelo planejamento da mesma, levantamento de requisitos, e podem manchar as
anlise, desenho, implementao, testes e avaliao, geralmente realizada metodologias geis.
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 interao 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 de os requisitos
serem definidos progressivamente com 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 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
CONCEITOS BSICOS 31
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 Cockbun (2003). Como alternativa a esse cenrio, surgiram os mtodos
geis que apesar de possurem documentao e alguma burocracia, so
mais flexveis, orientados a entregas e possuem uma maior interatividade 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 ideia 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.
O termo metodologias geis tornou-se popular em 2001, quando

diversos especialistas em processos de desenvolvimento de software
representando as metodologias Extremem 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:
1. Indivduos e interaes ao invs de processos e ferramentas;
2. Software executvel ao invs de documentao;
3. Colaborao do cliente ao invs de negociao de contratos;
4. Respostas rpidas a mudanas ao invs de seguir planos.
32 unidade 01
O Manifesto gil no rejeita os processos, as ferramentas,
a documentao, a negociao de contratos ou o planejamento, mas
simplesmente mostra que eles tm importncia secundria quando
comparados 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 forma com 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
interativo e incremental; comunicao e reduo de produtos intermedirios
e documentao extensiva. Desta forma, existem maiores possibilidades de
atender aos requisitos do cliente, que muitas vezes so mutveis.
Entrega evolutiva
Uma combinao muito

interessante entre o modelo em
cascata e o modelo incremental
o modelo de entrega evolutiva,
apresentado na Figura 12. 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 todas
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 Figura 12: Modelo de ciclo de vida entrega evolutiva.
CONCEITOS BSICOS 33
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.
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, o qual deve ser
robusta, mantendo-se ntegra ao longo dos 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 Process) e a PRXIS
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 PRXIS so baseados no
modelo em cascata. Esse um erro grosseiro e frequente. 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
O modelo de entrega apropriados; para projetos envolvendo equipes pequenas e cujos requisitos
evolutiva atual e
no sejam bem conhecidos, ou seja, muito instveis, os quais os processos
possui inmeros
casos de sucesso. baseados no modelo incremental so mais apropriados.
Muitos dos defensores De forma geral, o bom senso o melhor termmetro para definio
dos processos geis
do que mais apropriado em uma situao, mas um conselho a todos que
confundem a entrega
evolutiva com o possam se deparar com essa situao : nunca acredite em pessoas que
modelo em cascata, defendem cegamente esse ou aquele processo; como tudo na vida, o
o que representa um contexto da situao pode determinar o que mais apropriado.
erro absurdo.
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
34 unidade 01
RAD sejam modelos de ciclo de vida. No nosso ponto de vista, isso apenas
a definio de uso de certas tecnologias e que no geram ciclos de vida,
diferenciados do que j foi exposto neste captulo.
Exerccios de fixao
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. Descreva 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 modelo 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?
CONCEITOS BSICOS 35
36 unidade 01
UNIDADE 02
As Principais Disciplinas da
Engenharia de Software
Resumindo
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 Filho (2003) e seu Processo Prxis, 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.
AS PRINCIPAIS DISCIPLINAS DA ENGENHAIRA DE SOFTWARE 37

38 unidade 02
As principais disciplinas da
Engenharia de Software
Requisitos
Nesta unidade iremos apresentar os principais fluxos da Engenharia de

Software. Conforme comentamos, utilizaremos o livro do Prof. Wilson de Pdua
Filho (2003) como base nessa explicao. Esse livro descreve o Processo
Prxis, que ser brevemente apresentado a seguir, para ento darmos incio ao
detalhamento dos fluxos ligados Engenharia de Software.
Processo Prxis
O processo Prxis 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, a Prxis prope

um ciclo de vida composto por fases, divididas em uma ou mais interaes 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 interaes.
A Tabela 1 apresenta a diviso em fases e iteraes, enquanto a

organizao em fluxos descrita na Tabela 2.

NATUREZA FLUXO DESCRIO
Fluxo que visa a obter um conjunto de requisitos de um
Requisitos
produto, acordado entre cliente e fornecedor.
Fluxo que visa a detalhar, estruturar e validar os
requisitos de um produto, em termos de um modelo
Anlise conceitual do problema, de forma que eles possam
ser usados como base para o planejamento e controle
detalhados do respectivo projeto de desenvolvimento.
Fluxo que visa a formular um modelo estrutural do
produto que sirva de base para a implementao,
Desenho definindo os componentes a desenvolver e a reutilizar,
TCNICOS assim como as interfaces entre si e com o contexto do
produto.
Fluxo que visa a detalhar e implantar o desenho atravs
Implemen-
de
tao
componentes de cdigo e de documentao associada.
Fluxo que visa a verificar os resultados da
implementao, atravs do planejamento, desenho e
Testes
realizao de baterias de testes.
Gesto de Fluxo que visa a planejar e controlar os projetos de

Projeto software.
Gesto da Fluxo que visa a verificar e assegurar a qualidade dos
GERENCIAIS
Qualidade produtos e processos de software.
Tabela 1: Principais fluxos tcnicos e gerenciais do Prxis
Apesar de ter sido originalmente destinado utilizao em projetos

didticos das disciplinas de Engenharia de Software, o processo Prxis vem
sendo usado com sucesso tambm em projetos maiores, 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.
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
40 unidade 02
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 mais

investimento em Engenharia de Requisitos 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 muito ajudado pela experincia dos usurios com as verses
anteriores, uma vez que permite identificar de forma rpida e clara aquilo que
o mais importante, 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 identificarem o que mais importante, tornando igualmente difcil
para os desenvolvedores entenderem claramente o que os usurios desejam.
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 Processo
Prxis. 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 ambiguidade,

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:
1. Funcionalidade: O que o software dever fazer?
2. Interfaces externas: Como o software interage com as pessoas, com o

hardware do sistema, com outros sistemas e com outros produtos?

3. Desempenho: Qual o tempo de resposta mximo permitido dado a um contexto
de funcionamento, como por exemplo, 100 usurios realizando emprstimo de
um livro?
4. Outros atributos: Quais as consideraes sobre portabilidade, manutenibilidade

e confiabilidade que devem ser observadas?
5. Restries impostas pela aplicao: Existem padres e outros limites a serem

obedecidos, como linguagem de implementao, ambientes de operao, limites
de recursos etc.?
A Figura 13 apresenta as atividades do

fluxo de Requisitos do Processo Prxis. O fluxo
iniciado atravs da Determinao do contexto
que levanta 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.
A definio dos requisitos produz uma

lista de todos os requisitos funcionais e no
funcionais. Estes requisitos so descritos de
forma sucinta, ainda sem entrar em detalhes.
A Tabela 2 abaixo exibe um exemplo de

requisitos definidos para um produto responsvel
pelo controle de leitos hospitalares. 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, 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

Figura 13: Fluxo de requisitos.
42 unidade 02
mais detalhados, sendo provavelmente mais adequado que participem os
Um Caso de Uso
usurios chaves e no necessariamente pessoal gerencial do cliente. Ela
uma fatia de
ser revista nesta fase, normalmente com a participao de um nmero funcionalidade
maior de partes interessadas. do sistema, sem
superposio
NR CASO DE USO DESCRIO ou lacunas, que
Cadastro dos hospitais com leitos controlados representa algo de
1 Gesto de Hospitais
pelo SRLEP.
valor para os usurios
Cadastro dos leitos hospitalares controlados finais.
2 Gesto de Leitos
pelo SRLEP.
Autorizao de envio para Registro da autorizao da solicitao para
3
lista de espera constar na lista de espera por leitos.
Controle das internaes em leitos, com pos- Um Ator
sibilidade registro de alta, e consequente libera-
4 Controle de Internaes o do leito, alm de transferncias para outros representao dos
leitos. usurios e outros
sistemas que
5 Consulta Escala Visualizao de quadro de escala hospitalar.
interagem com o
Tabela 2: Exemplo de requisitos para um produto de software
produto.
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.
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
Um Diagrama de interfaces com outros sistemas e componentes de sistema. No Processo Prxis,
Casos de Uso exibe o detalhamento dos requisitos funcionais utiliza a notao de casos de uso.
os relacionamentos O fluxo de execuo das funes descrito de forma padronizada, dentro da
entre atores e casos
Especificao dos Requisitos do Software.
de uso, deixando claro
quais grupos utilizam Gesto de Condies de Internao
determinadas funes. 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 seus
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.
44 unidade 02
Exerccios de fixao
aconselhvel a
utilizao de um
1. Qual o objetivo do fluxo de requisitos? formato independente
de tecnologia para
2. Por que o levantamento de requisitos para produtos novos geralmente mais descrio das telas
difcil que para produtos j existentes? de um sistema. Isso
evita uma reduo no
3. O que deve conter uma especificao de requisitos? espao das solues.
Utilizar um componente
4. Quais as atividades de requisitos?
do tipo Select ou Radio
5. Em qual atividade feita uma descrio dos requisitos de forma sucinta? Button pode bloquear a
viso de desenvolvedor
6. Como so representados os grupos de usurios do produto? para solues mais
interessantes!
7. Que notao utilizada para descrio dos requisitos funcionais?
Um Diagrama de
8. Por que aconselhado fazer um esboo das telas de forma independente de Casos de Uso exibe os
tecnologia? relacionamentos entre
atores e casos de uso,
deixando claro que
grupos utilizam quais
Fluxo de anlise
funes.
O fluxo da anlise tem como objetivos: Na disciplina
1. Modelar de forma precisa os conceitos relevantes do domnio do problema, Requisitos de Software
ser detalhado o
identificados a partir do levantamento de requisitos;
fluxo de requisitos e
2. Verificar a qualidade dos requisitos identificados; anlise. Iremos realizar
diversas prticas
3. Detalhar esses requisitos o suficiente para que atinjam o nvel de detalhe relacionadas ao tema.
adequado aos desenvolvedores.
No processo Prxis, 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 se deve 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:
1. Os casos de uso descrevem o comportamento esperado do produto. Seus

diagramas descrevem os relacionamentos dos casos de uso entre si e com os
atores;
2. 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 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
46 unidade 02
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 relacionamentos determina os relacionamentos de vrios
tipos que podem existir entre os objetos das classes identificadas.
Figura 17: Exemplo de diagrama de classes exibindo classes, atributos e relacionamentos

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.
Em paralelo, a realizao dos casos de uso verifica os fluxos dos casos

de uso, representando-os atravs de diagramas de interao. Estes mostram
O diagrama de
classe fornece como os fluxos so realizados atravs de trocas de mensagens entre os objetos
uma viso geral do das classes encontradas. Isso ajuda a localizar imprecises e outros tipos de
sistema e representa problemas nos fluxos e permite definir as operaes das classes de anlise.
um artefato
imprescindvel no Por fim, a Reviso da anlise valida o esforo de Anlise e o
desenvolvimento. correspondente esforo de Requisitos. Podem acontecer vrias revises
informais, individuais ou em grupo (por exemplo, dentro de uma oficina de
detalhamento dos requisitos).
Exerccios de fixao
1. Qual o objetivo do fluxo de anlise?
2. uais 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?
Fluxo de 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 o conceito relacionado ao domnio do problema, enquanto
o Desenho visa modelar o conceito relacionado a uma soluo para o problema.
48 unidade 02
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 Processo Prxis separa bem esses dois conceitos. Nesse
caso, ento, o desenho de um produto de software deve considerar os
seguintes aspectos:
1. O atendimento dos requisitos no funcionais como os requisitos de

desempenho e usabilidade;
2. A definio de classes e outros elementos de modelo em nvel de detalhe

suficiente para a respectiva implementao;
3. 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;
4. 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;
5. A documentao das decises de desenho, de forma que estas possam

ser comunicadas e entendidas por quem vier a implementar e manter o
produto;
6. A reutilizao de componentes, mecanismos e outros artefatos para

aumentar a produtividade e a confiabilidade;
7. O suporte a mtodos e ferramentas de gerao semiautomtica 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 treinados nas respectivas tcnicas.

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
necessrios para
implementar um novo
projeto.
Figura 18: 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
50 unidade 02
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 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
Um framework ou
devem ser registradas e comunicadas equipe. arcabouo uma
abstrao que une
cdigos comuns entre
vrios projetos de
software, provendo
uma funcionalidade
genrica e facilitando o
seu uso.
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.
No fluxo de desenho O detalhamento dos casos de uso resolve os detalhes dos fluxos dos
devemos identificar
casos de uso de desenho, considerando os componentes reais das interfaces.
os padres a serem
seguidos no projeto. Todos os fluxos alternativos devem ser detalhados, inclusive os que consistem
Padres so solues de emisso de mensagens de exceo ou erro. Se esta atividade for feita de
bem conhecidas para forma completa, pode-se deixar a cargo de profissionais de redao tcnica a
problemas recorrentes.
confeco da documentao para usurios e at das mensagens aos usurios.
So exemplos de
problemas recorrentes: Os fluxos dos casos de uso de desenho so tambm a base para o desenho
como criar uma classe dos testes de aceitao e a referncia para os implementadores quanto ao
e garantir que haver comportamento desejado para o produto.
somente uma instncia
dela ativa no sistema? A atividade de Desenho das entidades transforma as classes de entidade
O padro Singleton nos do Modelo de Anlise nas classes correspondentes do Modelo de Desenho.
ensina como resolver Inclui-se aqui a considerao de possvel reutilizao dessas classes, ou de
esse problema de
transformao delas em componentes fisicamente distintos. Muitos detalhes
forma simples, sem
termos que perder irrelevantes para a Anlise devem ser ento decididos como a visibilidade das
tempo pensando operaes e a navegabilidade dos relacionamentos. Inclui-se aqui tambm a
nessa soluo. Nas tomada de decises sobre como sero representados os relacionamentos; no
referncias citamos
caso de multiplicidades maiores que valor um, geralmente essa representao
o livro mais famoso
relacionado a padres, envolve o desenho de colees de objetos.
escrito por quatro A atividade de desenho da persistncia trata da definio de estruturas
profissionais altamente
externas de armazenamento persistente como arquivos e bancos de dados. Dois
reconhecidos no mundo
e citados como sendo problemas devem ser resolvidos: a definio fsica das estruturas persistentes
a Gangue dos Quatro externas como o esquema de um banco de dados e a realizao de uma ponte
(Gang Of Four GoF). 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
Scott Ambler discute bem desenhada, altamente reutilizvel, muitas vezes a atividade se reduz a
sobre camadas de adaptaes de componentes j existentes.
persistncia em um artigo
referenciado no mundo
A Realizao dos casos de uso determina como os objetos das classes
inteiro. Confira na Web- de desenho colaboraro para realizar os casos de uso. As classes da camada
bibliografia! de controle contero o cdigo que amarra essas colaboraes, de maneira a
obter 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
52 unidade 02
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 interao, o Processo Prxis padro prev revises tcnicas da Descrio
do Desenho ou inspees que focalizam principalmente o Modelo de Desenho.
Exerccios de fixao
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?
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:
1. Planejamento detalhado da implementao das unidades de cada iterao;
2. Implementao das classes e outros elementos do modelo de desenho, em

unidades de implementao, geralmente constitudas de arquivos de cdigo
fonte;
3. Verificao das unidades, por meio de revises, inspees e testes de unidade;

4. Compilao e ligao das unidades;
5. Integrao das unidades entre si;
6. Integrao das unidades com componentes reutilizados, adquiridos de

terceiros ou reaproveitados de projetos anteriores;
7. 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 manuais de usurios, ajudas on-
line, stios Web integrada 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: Fluxo de implementao.
54 unidade 02
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 em nvel necessrio para guiar a codificao. Nessa reviso so
conferidos os detalhes de interfaces, lgica e mquinas de estado das operaes.
O uso de linguagens
orientadas a
objetos virou um
padro mundial
de programao
atualmente.
Linguagens como C e
Java so disparadas
como as linguagens
mais utilizadas para o
desenvolvimento de
novos sistemas.
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 incluindo 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 por meio da compilao.

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 dessas 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 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.
56 unidade 02
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.
Exerccios de fixao
1. Qual o objetivo do fluxo de implementao?
2. O que significa integrar no fluxo de implementao?
3. Em qual atividade feita 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?

TESTES
Na disciplina
Qualidade de
Software ser O Teste de Software a verificao dinmica do funcionamento de
detalhado o fluxo de um programa utilizando um conjunto finito de casos de teste, adequadamente
teste e realizadas escolhido dentro de um domnio de execuo infinito, contra seu comportamento
diversas prticas
esperado. Nesse conceito existem alguns elementos chaves que merecem mais
relacionadas ao tema.
detalhamento:
1. Dinmica: o teste exige a execuo do produto, embora algumas de suas

atividades possam ser realizadas antes de o produto estar em operao;
2. Conjunto finito: o teste exaustivo geralmente impossvel, mesmo para

produtos simples;
3. Escolhido: necessrio selecionar testes com alta probabilidade de encontrar

defeitos, preferencialmente com o mnimo de esforo;
4. Comportamento esperado: para que um teste possa ser executado,

necessrio saber o comportamento esperado, para que ele possa ser comparado
com o obtido.
No processo Prxis 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 testes
existentes so: testes de aceitao, testes de integrao e testes de unidade.
Um caso de teste especifica como deve ser testada 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:
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.
IDENTIFICAO PROCEDIMENTO DE TESTE LOGIN

OBJETIVO EFETUAR O LOGIN DE UM USURIO NO MERCI.
58 unidade 02
REQUISITOS ESPECIAIS A TELA PRINCIPAL DEVE ESTAR NO ESTADO SEM USUARIO.
1. PREENCHER O CAMPO LOGIN E SENHA

FLUXO
2. PRESSIONAR O BOTO LOGIN
IDENTIFICAO Login invlido com caracteres no permitidos

Verificar se a tentativa de login utilizando um identificador inv-
ITENS A TESTAR lido, contendo caracteres no permitidos, exibe a mensagem ap-
ropriada.
Campo Valor
ENTRADAS Login Pasn!
Senha Aaaa
Campo Valor
SADAS
Login Pasn!
ESPERADAS
Senha aaaa (exibida com *s)
ESTADO SEM USURIO
ALCANADO
AMBIENTE Banco de dados de teste.
PROCEDIMENTOS Procedimento de Teste Login
DEPENDNCIAS No aplicvel.
Tabela 4: Exemplos de procedimento de teste
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 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: Fluxo de teste.
O grupo de preparao compreende as atividades de planejamento

que produz o plano de testes da bateria e Desenho 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
60 unidade 02
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 Na Web-bibliografia
apresentamos o
em que a cultura da organizao absorva esses testes, passa a preparar e
stio do Brazilian
realizar tambm os testes de integrao. Software Testing
Qualification Board,
que responsvel
Exerccios de fixao pela Certificao
Brasileira de Teste
de Software. Essa
1. O que o teste de software? certificao atribuda
ao profissional que
2. O que um procedimento de teste? O que um caso de teste? Qual a ligao aprovado na prova e
que existe entre esses dois conceitos? garante, assim, que ele
possui conhecimento
3. As atividades de teste so divididas em dois grandes grupos. Quais so eles? na rea. De acordo
com diversas
4. Quais so os objetivos do teste de aceitao?
pesquisas de mercado
feitas recentemente,
os profissionais de
Gesto de Projetos teste esto entre os
mais procurados e
Este tpico trata dos principais mtodos de gesto de projetos de desenvolvimento
mais bem remunerados
de software. Os seguintes tpicos so brevemente apresentados aqui: profissionais de
informtica do mundo.
1. Os procedimentos de gesto dos requisitos, que regulam o cadastramento, a
manuteno e a alterao dos requisitos de um projeto de software;
2. Os procedimentos de planejamento de projetos, que tratam da previso de

tamanho, esforos, recursos, prazos e riscos de um projeto de software;
3. 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 subsequentes 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 necessrios para tal realizao. O Planejamento de Projetos

refere-se ao processo de estimar os recursos, esforo e prazo necessrios
Na Web-bibliografia para se desenvolver um software ou parte dele, com base nos dados histricos
apresentamos o
mantidos pela organizao.
stio do Project
Management Institute O Controle de Projeto refere-se s tarefas de verificao comumente
- PMI. O PMI uma
executadas durante o desenvolvimento e ao monitoramento dos riscos e da
entidade mundial
sem fins lucrativos evoluo esperada, sempre prescrevendo aes quando o estimado diferir muito
voltada definio do planejado.
de boas prticas do
Na prxima unidade apresentamos um exemplo de um processo de
gerenciamento de
projetos. 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
62 unidade 02
Exerccios de fixao
1. O que significa Gesto de Requisitos?
2. O que o Planejamento de Projeto?
3. Quais so as aes associadas ao Controle de Projeto?

64 unidade 02
UNIDADE 03
Exemplo de um processo
de software
Resumindo
Nesta unidade apresentaremos um processo de software baseado nos princpios da agilidade, alm
de apresentarmos seu uso para uma tarefa simples. No capitulo 9 apresentaremos as prescries
do processo SCRUM, que vem se destacando no cenrio industrial de desenvolvimento de
software, sendo cada dia mais utilizado por diversas organizaes. Apresentaremos os principais
papis associados ao seu uso, alm das cerimnias previstas durante sua utilizao, detalhando
os artefatos que devem ser gerados. No captulo 10 apresentaremos um exemplo da aplicao do
SCRUM para guiar a execuo de um projeto simples, ilustrando como utilizar o processo para
qualquer atividade em que se desejar ter mais controle sobre sua execuo.
EXEMPLO DE UM PROCESSO DE SOFTWARE 65

66 unidade 03
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 intitulado 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, documentou e implementou 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 Scrum uma
disposio de
todo o mundo.
jogadores de um
O Scrum utilizado com sucesso em diversas empresas de time de Rugby,
desenvolvimento de software. Porm, este mtodo pode ser utilizado em qualquer utilizada para
contexto em que uma equipe, composta por diversas pessoas, necessite trabalhar reincio do jogo em
unida para atingir um objetivo comum. Empresas como a Microsoft, Yahoo, certos casos.
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, videogames, websites e O Scrum utiliza o
modelo de ciclo de
muitas outras aplicaes.
vida incremental,
Ken Schwaber define o Scrum como um guia geral de como fazer conforme discutido
desenvolvimento de produtos, com a finalidade de fazer a equipe pensar anteriormente.
diferente.
Segundo ele, o desenvolvimento de 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, em que 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 entregar 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 disciplina, uma vez que no haver muitas regras e
nem interferncia externa na execuo das tarefas.
A evoluo do desenvolvimento de um sistema feita com base em
uma srie de perodos definidos de tempo, chamados Sprints, que variam,
preferencialmente, de 2 a 4 semanas. Durante esse tempo, os requisitos so
Embora os Processos detalhados, o produto projetado, codificado e testado. Ao final de cada Sprint
geis prescrevam feita uma avaliao do que estava programado, assim o acompanhamento
menos burocracia no feito em curtos espaos de tempo.
seu uso, eles exigem
O desenvolvimento feito de forma paralela em detrimento do
alguma burocracia e
no segui-la significa desenvolvimento sequencial (modelo de ciclo de vida em cascata), ou seja, as
anarquia. 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 dos processos geis reduzir ao mximo o trabalho
burocrtico. Apresentaremos juntamente com as cerimnias os principais
artefatos produzidos, exibindo alguns exemplos prticos do mesmo.
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. O ideal seria que a pessoa com
tal responsabilidade fosse um representante dos clientes do produto, embora
68 unidade 03
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 O Scrum Master o
papel chave no Scrum.
deve manter uma vigilncia contnua sobre o uso correto das prescries do
Ele deve garantir o uso
Scrum, garantindo assim a disciplina de todos os membros da equipe. Embora do processo e eliminar
os processos geis tenham um mnimo de burocracia, ainda existe burocracia interferncias externas.
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 tcnico suficiente para entender todo o
desenvolvimento e ajudar sempre que necessrio.
A Equipe no Scrum normalmente composta de 5 a 9 membros, embora Embora o Scrum
tenha sido criado para
o Scrum possa ser aplicado com mais colaboradores ou apenas um colaborador.
equipes pequenas,
A diferena que aplicar o Scrum com um membro apenas torna sem sentido existem relatos de
algumas das prticas previstas no processo. No entanto, ainda assim o seu uso projetos com grandes
garante um controle nas atividades sendo executadas e um conhecimento na equipes utilizando essa
produtividade, fato esse que s tem a acrescentar a qualquer tipo de trabalho. metodologia. Existe
o conceito de Scrum
Os membros da equipe devem ser multifuncionais, ou seja, eles devem ser
aplicado justamente
capazes de executar diversos tipos de tarefas, desde a modelagem at o teste nesse caso.
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.
Cerimnias
As cerimnias se referem 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.

Reunio inicial
No incio do projeto necessrio fazer o levantamento de requisitos

do produto a ser desenvolvido. No caso dos processos 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 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
O levantamento de feita com a participao de toda a equipe, juntamente com o Product Owner
requisitos durante e, opcionalmente, outros membros representantes dos clientes. Essa reunio
o uso do Scrum geralmente dura um ou mais dias, com bastante conversa sobre as estrias do
acontece durante
produto. fundamental ressaltar que o mais importante nesse momento no
todo o projeto,
mas a identificao obter um entendimento detalhado sobre o produto, mas identificar as funes
desses requisitos, existentes que devem ser tratadas a posteriori.
descrevendo-os O registro dos dados coletados na reunio um ponto crucial para o
de forma sucinta,
restante do processo. necessrio registrar tudo o que foi discutido, pois cada
acontece na reunio
uma dessas estrias ser utilizada no decorrer do projeto. Tambm importante
inicial.
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, perguntar 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: De 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 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.
70 unidade 03
Um ponto interessante em cada questo tentar identificar quem o
responsvel pelas aes. Isso normalmente est relacionado a papis dentro do
produto, os quais representam responsabilidades e no pessoas. Cada estria
normalmente possui um papel associado a sua execuo.
As estrias e os papis 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.
Diagramas de caso
de uso fornecem
uma boa viso dos
grupos de usurios
do sistema e suas
funcionalidades
associadas.
Figura 25: Exemplo de Diagrama de Caso de Uso
A Figura 25 apresenta um exemplo de um Diagrama de Caso de Uso

que exibe dois papis (regulador e intensivista) e algumas funes do produto
(autorizao de envio para lista de espera, 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 4. Um exemplo do detalhamento dos papis (ou atores) apresentado
na Tabela 5.

Nmero de
Casos de uso Descrio
ordem
Registro da autorizao da
Autorizao de envio para Lista de
1. solicitao para constar na
Espera
lista de espera por leitos.
Controle da lista de espera
por leitos, com registro de
evoluo dos pacientes,
2. Controle da Lista de Espera alm de registro de en-
trada ou encaminhamento
em leitos hospitalares e
eventual remoo da lista.
Controle das internaes
em leitos, com possi-
bilidade registro de alta, e
3. Controle de Internaes
consequente liberao do
leito, alm de transfern-
cias para outros leitos.
Cadastro das solicitaes
de leitos para pacientes
4. Cadastro de Solicitao de Leito
com necessidades de
internao.
Tabela 4: Detalhamento dos casos de uso
Nmero de
Ator Definio
ordem
Mdico plantonista que
coordena a UTI no hospital
1. Intensivista
e faz a solicitao das
vagas.
Mdico regulador da
Central de Leitos, que
2. Regulador recebe, avalia e gerencia
as solicitaes e eventuais
internaes..
Tabela 5: Detalhamento dos atores
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
72 unidade 03
conjunto dos requisitos do produto 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.
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,
A reunio de
quando precisamos ter respostas mais rpidas e obter dados sobre produtividade, planejamento
ou maiores, quando as coisas j esto mais estveis e podemos nos dar ao luxo a cerimnia mais
de adiar a entrega para o cliente para termos mais itens desenvolvidos. importante do Scrum e
deve ser realizada com
Definido o tamanho do Sprint, hora de calcular a fora de trabalho que
muito cuidado.
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 teis do Sprint.
Essa a fora de trabalho bruta. Normalmente utiliza-se um fator de ajuste
necessria muita
para encontrarmos a fora de trabalho lquida. O fator de ajuste corresponde ao
prudncia para
percentual de tempo produtivo efetivamente utilizado para computar carga de definio da dedicao
trabalho da equipe. dos colaboradores
Colaboradores que trabalham 8h/dia dificilmente passam 8h realizando ao projeto, pois isso
tarefas diretamente relacionadas ao desenvolvimento. Existe tempo para ler pode gerar grandes
problemas no Sprint.
e-mails, conversar com colegas, tomar caf, ir ao banheiro, etc. Um fator de
Um fator comum
ajuste muito comum usar 75%, mas esse nmero depende de vrias condies superestimar a
que devem ser analisadas. participao dos
Um ponto importante na definio da dedicao da equipe nunca membros, esquecendo-
se de outras tarefas
considerar o Scrum Master nem o Product Owner (caso esse seja um membro
existentes!
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
expressa na figura. Na coluna Total feito o clculo das horas disponveis durante
o Sprint, levando em 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 traar 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
descreveu como o grfico dever ser utilizado.
Figura 27: Grfico de acompanhamento.
74 unidade 03
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 apenas uma.
Tudo depende da situao.
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:
1. ID: identificador da tarefa;
2. Nome: descrio resumida da tarefa para fcil identificao;
3. Descrio: texto simples e objetivo descrevendo a tarefa com mais detalhes;
4. Como verificar: indicao de como deve ser feita a verificao dessa tarefa,
quando a mesma estiver concluda;
5. Tempo estimado: tempo especificado pela equipe para realizao da tarefa;
6. Tempo real: tempo efetivamente utilizado para realizao da tarefa;
7. Responsvel: colaborador encarregado de realizar a tarefa.
Figura 28: Exemplo de carto descrevendo uma atividade
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 vir-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,
importante por exemplo, que estimativas muito diferentes possam acontecer. Por conta
que todos faam disso, existem algumas definies para as cartas que merecem ateno:
suas estimativas 1. Um ? indica que mais explicaes so necessrias;
sem conhecer as
2. Um 0 indica algo to pequeno que no merece estimar;
estimativas dos
outros membros do 3. Uma xcara indica necessidade de tempo para pensar e hora para o caf...
grupo para evitar Tarefas acima de 16h merecem ser divididas, pois caso contrrio
interferncias nas podem gerar problemas no acompanhamento, por serem grandes demais e
opinies. Mas necessitarem de vrios dias para se descobrir que ela est atrasada! Estimativas
fundamental
muito diferentes merecem explicaes
conversar quando
grandes diferenas
so registradas!
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 temos 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 a concluso da tarefa, independente do tempo estimado. A
76 unidade 03
partir do confrontamento entre o tempo estimado e o tempo real que poderemos
apurar nossas estimativas e assim chegarmos a um ponto onde o erro possa ser
considerado desprezvel.
A princpio, 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 realmente tenha sido concretizada.
Outro item importante a ser verificado durante o planejamento a
Definio de Feito (DoD). Todo projeto deve ter uma definio clara sobre o que
considerado feito! Para uma tarefa de modelagem, por exemplo, poderamos
considerar uma tarefa efetivamente concluda apenas se existisse:
1. Diagrama representando a modelagem feita na ferramenta de modelagem Sem a definio de
feito clara e precisa
definida no projeto;
comum que as tarefas
2. Diagrama contido em um repositrio do projeto; entrem e saiam da
3. Reviso em conjunto com o Scrum Master. coluna Concluda,
Outro ponto prescrito pelo Scrum so as reunies dirias, que retornando para em
abordaremos a seguir. Durante o planejamento importante a definio do local Execuo, por diversas
vezes, sem que
e horrio dessas reunies.
estejam efetivamente
Por fim, um quadro com as informaes do Sprint precisa ser criado. Um terminadas.
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
estado 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 Master no a considere concluda durante a verificao que sempre
exigida nesses casos.

Figura 30: Exemplo da organizao do 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
importante equipe e o restante da organizao, sendo elas:
manter o quadro 1. rea para Objetivo do Sprint;
do projeto
2. rea para o Grfico de Acompanhamento;
com todas
as definies 3. rea para especificar a equipe;
registradas aqui! 4. rea para detalhar a data de incio e fim do Sprint;
5. rea para especificar dia da apresentao dos resultados;
6. rea para especificar local e horrio das reunies dirias;
7. rea para especificar o dia da retrospectiva do Sprint.
Figura 31: Mudanas permitidas no quadro do Sprint.
78 unidade 03
Reunio diria
A Reunio Diria uma prtica feita com toda a Equipe, o Scrum Master
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 s seguintes perguntas: O que
voc fez de ontem para hoje? O que far de hoje at amanh? Existe algum
impedimento?
Na reunio no se resolvem 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. A reunio diria tem
que ser rpida, caso
contrrio, perder
Acompanhamento do projeto sua efetividade.
O Scrum Master possui diversas tarefas no controle dirio do projeto,
alm da reunio diria:
1. Verificar tarefas concludas;
2. Atualizar grfico de acompanhamento;
3. Resolver impedimentos;
4. 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, 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 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 Master 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-lo,
caso contrrio, todo o projeto poder ser comprometido.
Apresentao do Sprint
Ao final de um Sprint, o Scrum recomenda que seja feita a apresentao

dos resultados. Essa apresentao tipicamente se resume 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.
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:
1. O que voc achou melhor no Sprint e o que deveria continuar sendo feito?
2. O que voc achou ruim e no deveria mais ser feito (ou mudado)?
3. 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. Com
80 unidade 03
base nessa identificao que registraremos o que foi mais consensual para
cada uma das trs questes. O Scrum Master deve ficar atento a esses itens e
garantir que eles sero levados em considerao no prximo Sprint.
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.
1. Qual a origem do Scrum?

2. Quais so os papis relacionados ao uso do Scrum? Detalhe as
responsabilidades 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 v
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 Master durante o dia a dia dos
projetos?
13. O que deve ser feito na reunio de retrospectiva do Sprint? Como isso pode
ser guiado?
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, mas envolve 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.
Qualquer trabalho No entanto, esse exemplo servir para mostrar a dinmica maior do processo e
pode ser controlado
o controle que ele pode nos dar durante o desenvolvimento de qualquer tarefa.
com auxlio do Scrum.
Vrias equipes de
empresas que no Exemplo
trabalham com
Conforme mencionado anteriormente, utilizaremos como exemplo o
desenvolvimento
de software utilizam desenvolvimento de um livro introdutrio sobre Engenharia de Software.
Scrum para controlar Depois de alguns momentos de reflexo fizemos a construo do Backlog
suas atividades. desse projeto, que seria composto basicamente pelas seguintes tarefas exibidas
na tabela 6. Nela, as prioridades definidas para as atividades j se encontram
especificadas.
ID NOME PRIORIDADE
1 Estudar conceitos bsicos, proces- 80
sos e ciclo de vida
2 Escrever captulo introdutrio 60
3 Escrever captulo sobre processos 60
4 Estudar as disciplinas da Engen- 50
haria de Software
5 Escrever captulos sobre as princi- 40
pais disciplinas
6 Estudar a metodologia Scrum 30
7 Escrever captulo sobre o Scrum 20
Tabela 8 : Product Backlog para o exemplo considerado
82 unidade 03
Figura 32: Dados do Sprint e Grfico de Acompanhamento
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.
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 ajuda de outras pessoas nessa empreitada por se
tratar de um trabalho individual. Isso tem a ver 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:
1. Para tarefas relativas a estudos: breve resumo do item estudado, com
detalhamento das referncias utilizadas;
2. 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 agilizar o processo. Observe que essas estimativas
podem ser alteradas, desde que a tarefa com a estimativa a ser alterada no se
encontre no Sprint em execuo. As tarefas e suas estimativas so apresentadas
na Tabela 7.
ID NOME PRIORIDADE TEMPO

ESTIMADO
1 Estudar conceitos bsicos, processos e 80 4
ciclo de vida
2 Escrever captulo introdutrio 60 4
3 Escrever captulo sobre processos 60 6
4 Estudar as disciplinas da Engenharia de 50 8
Software
5 Escrever captulos sobre as principais 40 4
disciplinas
6 Estudar a metodologia Scrum 30 4
7 Escrever captulo sobre o Scrum 20 4
Tabela 7: Tarefas com estimativa de execuo
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 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.
Figura 33: Grfico de acompanhamento aps a primeira semana de trabalho
84 unidade 03
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.
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 8. 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.
TEMPO TEMPO
ID NOME PRIORIDADE
ESTIMADO GASTO
Estudar conceitos bsi-
1 cos, processos e ciclo 80 4 3
de vida
Escrever captulo in-
2 60 4
trodutrio
Tabela 8: Registro dos tempos gastos nas tarefas

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.
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 ncleos de tecnologia e se espalhado nos outros setores das
empresas 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.
Exerccios de fixao
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 neste captulo. Faa um
breve relato sobre o uso do processo para controlar essa atividade.
WEB-BIBLIOGRAFIA
Manifesto gil disponvel em: <http://agilemanifesto.org/>

Stio de apoio ao livro de Wilson de Pdua disponvel em: <http://homepages.
dcc.ufmg.br/~wilson/>
86 unidade 03
<http://www.ambysoft.com/>
<http://www.bstqb.org.br/>
<http://www.comp.lancs.ac.uk/computing/resources/IanS/>
<http://www.controlchaos.com/>
<http://www.inf.pucrs.br/~rafael/Scrumming/>
<http://www.infoq.com/br/>
<http://www.mountaingoatsoftware.com/>
STORM (Software Testing Online Resources). Stio com diversos materiais sobre
testes, desde ferramentas, artigos, livros, etc. Disponvel em:
Vdeos e tutoriais sobre o Scrum disponvel em:<http://www.mtsu.edu/~storm/>
Project Management Institute (PMI) disponvel em: <http://www.pmi.org/>
<http://www.rspa.com/>
Stio de apoio ao processo Prxis, com exemplos da aplicao dos fluxos em
um exemplo real de desenvolvimento disponvel em: <http://www.Scrumalliance.
org/ >
<http://www.sei.cmu.edu/>
Relatrios do Standish Group, incluindo dados sobre desenvolvimento de
software disponvel em: <http://www.standishgroup.com>
Pgina da Universidade Aberta do Brasil- UAB disponvel em:
<http://www.uab.gov.br>
Pgina da Universidade Aberta do Piau UAPI disponvel em: <http://www.ufpi.
br/uapi>
Certificao Brasileira de Teste de Software disponvel em:
Empresa com diversos artigos e casos de sucesso no uso de prticas geis
disponvel em:
Instituto de Engenharia de Software do MIT disponvel em:
Organizao divulgadora do Scrum mundialmente disponvel em:
Pgina de Scott Ambler com boas prticas para o desenvolvimento de software
disponvel em:
Stio com um livro disponvel para download em:
Stio de apoio ao livro de Ian Sommerville disponvel em:
Stio de apoio ao livro de Roger Pressman disponvel em:
Srcumming - Ferramenta Educacional para Apoio ao Ensino de Prticas de
Scrum disponvel em:

88 unidade 03
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. 2

edio, 1997.
EDSGER, W. Dijkstra. The humble programmer, Communications of ACM,

Volume 15, nmero 10, pginas 859-866, outubro de 1972.
FILHO, Wilson de Pdua Paula. Engenharia de Software: Fundamentos,

Mtodos e Padres. Editora LTC. 2 Edio, 2003.
FREDERICK, P. Brooks. No silver bullet: essence and accidents of software

engineering. Computer Magazine, Abril de 1987.
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.
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.
IAN, Sommerville. Engenharia de Software. 6. Edio. Addison-Wesley, 2005.

IEEE. Guide to the Software Engineering Body of Knowledge (SWEBOK).
Editores: Alain Abran e James W. Moore, 2004.
KEN SCHWABER. Agile Project Management with Scrum. Microsoft Press,

2004.
______________. Scrum Development Process, Burlington, MA. USA, 1996.
KENDALL, Scott. Processo Unificado Explicado. Editora Bookman, 2003.
KENT, Beck. Extreme Programming Explained: embrace change. Boston:

AddisonWesley/Longman, 1999.
RICHARD, Fairley. Software Engineering Concepts. New York: McGraw-Hill,

1985.
ROGER, S. Pressman. Engenharia de Software. 5. Edio, So Paulo:

McGraw-Hill, 2002.
STANDISH, The Standish Group International; CHAOS Demographics and

Project Resolution, Dennis, MA, USA, 2004.
STEVE, Macconnell. Rapid Development. Microsoft Press, 1996.
TELES, Vinicius Manhes. Extremme Programming. Editora Novatec, 2004.
W. WAYT, Gibbs. Softwares chronic crisis, Scientific American. Setembro de

1994.
90 unidade 03
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.

Introdução À Engenharia de Software

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Introdução À Engenharia de Software

Hochgeladen von

Copyright:

Verfügbare Formate

Universidade Federal do Piau

Centro de Educao Aberta e a Distncia

Pedro de Alcntara dos Santos Neto

EQUIPE DE DESENVOLVIMENTO CONSELHO EDITORIAL DA EDUFPI

S237i Santos Neto, Pedro de Alcntara dos.

1. Engenharia de Sftware. 2. Software - Desenvolvi-

A partir de 1961, o mundo presenciou o surgimento de novos

Figura 1: Fotos da NATO Software Engineering Conference.

A NATO Software Engineiring Conference marcou o incio de uma

Em 1972, Dijkstra recebeu o Prmio Turing (Turing Award), que

A maior causa da crise do software que as mquinas tornaram-se

1. Projetos estourando o oramento;

2. Projetos estourando o prazo;

3. Software de baixa qualidade;

4. Software muitas vezes no atendendo aos requisitos;

5. Projetos no gerenciveis e cdigo de difcil manuteno.

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

Mesmo com a evoluo dos computadores, das tcnicas e ferramentas

Ser que a crise acabou?

Desse ponto adiante existe uma srie de entendimentos diferentes,

Embora problemas durante o desenvolvimento de software aconteam

Figura 4: Passos para desenvolvimento de um carro

A Figura 4 apresenta os passos para desenvolvimento de um carro.

O modelo criado, seja qual for, normalmente utilizado para

Caso os componentes sejam aprovados na verificao, podemos iniciar

Caso os componentes agrupados continuem funcionando conforme o

Mas por que conversar sobre carros se o objetivo desta seo

Em resumo e utilizando termos mais formais, podemos dizer que

Na literatura, podem-se encontrar mais definies para Engenharia

Conjunto de mtodos, tcnicas e ferramentas necessrias produo

Num ponto de vista mais formal, a Engenharia de Software pode

Os dois fatores motivadores so, essencialmente, a qualidade

Um grande problema facilmente percebido hoje justamente o fato de

Problemas no desenvolvimento de software

Embora a Engenharia de Software seja uma rea consolidada e

Figura 5: Trip da Engenharia de Software.

A Figura 5 apresenta o trip no qual a Engenharia de Software

Da mesma forma, no adianta possuir as tecnologias mais avanadas

Figura 6: Componentes de um sistema.

Um conceito que muitas vezes causa confuso o de sistema, que

Um produto de software (ou software, como vamos chamar ao longo

Resumindo, um programa desenvolvido para resolver um dado

importante ressaltar que isso inconcebvel em qualquer rea,

Em resumo, os sistemas informatizados normalmente no fazem

Software: mitos e realidade

Muitas causas de problemas relacionados ao desenvolvimento

Mito 1. Se a equipe dispe de um manual repleto de padres e procedimentos

Realidade 1. Isso no o suficiente! preciso que a equipe aplique

Realidade 2. Ter sua disposio o ltimo modelo de computador pode ser

Mito 3. Se o desenvolvimento do software estiver atrasado, aumentando a

Realidade 3. Acrescentar pessoas em um projeto atrasado provavelmente

Mito 4. Uma descrio breve e geral dos requisitos do software o suficiente

Realidade 4. Este um dos problemas que podem conduzir um projeto

Mito 5. Os requisitos de projeto mudam continuamente durante o seu

Realidade 5. verdade que o software flexvel (pelo menos mais flexvel

DEFINIO DESENVOLVIMENTO DENOMINAO

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

Mito 6. Aps a finalizao do programa e a sua implantao, o trabalho est

Realidade 6. O que ocorre, na realidade, completamente diferente disso.

Mito 7. Enquanto o programa no entrar em funcionamento, impossvel

Realidade 7. Na realidade, a preocupao com a garantia da qualidade do

Mito 8. O produto a ser entregue no final do projeto o programa funcionando.

Realidade 8. O programa em funcionamento um dos componentes do