Aula01_Item 8, Até Metodologias Ágeis-CEF

Edited with the trial version of
Foxit Advanced PDF Editor

To remove this notice, visit:
www.foxitsoftware.com/shopping
Aula 01
Curso: Tecnologia da Informao p/ Caixa Econmica Federal (tpicos 8,9, 10, 11, 12 e
14)
Professor: Diego Carvalho

Tecnologia da Informao para Caixa Econmica Federal
Curso de Teoria e Exerccios CEF
Prof. Diego Carvalho Aula 01
AULA 01
SUMRIO PGINA
Apresentao 01
Informaes sobre o concurso 02
Informaes sobre o curso 03
Cronograma do concurso 04
Sobre as aulas... 05
Ciclo de Vida e Metodologias de Desenvolvimento de Software 07
Processo Unificado: Disciplinas, Fases, Papis e Atividades 27
Metodologias geis 36
Modelagem de Processos 47
Exerccios Comentados (48) 53
Lista de Exerccios Comentados 64
Gabarito 68
APRESENTAO
Ol, pessoal. Sejam bem-vindos! O Edital da Caixa Econmica Federal (CEF) saiu, trazendo
vagas para os candidatos da rea de Tecnologia da Informao e por essa razo que eu
estou aqui. As provas sero aplicadas no dia 2 03/2014, portanto vocs tm cerca de dois
meses at a prova. Meu objetivo fazer vocs acertarem a maior quantidade de itens! =)
Breve apresentao: meu nome Diego Carvalho, bacharel em Cincia da Computao

pela Universidade de Braslia, ps-graduado em Gesto de Tecnologia da Informao na
Administrao Pblica e recm aprovado no Concurso da Secretaria do Tesouro Nacional
para Analista de Finanas e Controle Governana e Gesto em TI, em 5 lugar.
No se enganem 01176992910
com esse salrio,

em dois anos isso j
pode subir para uns
R$7.000. Galera...
devo admitir para
vocs uma coisa:
es pegaram
pesado para um
concurso de nvel
mdio, mas fazer o que?! O nvel dos concursos s aumenta e a consequncia que vocs
tenham que estudar cada vez mais. Desejo boa sorte a vocs e contem comigo ;D
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 1 de 68

INFORMAES SOBRE O CONCURSO
Concurso da Caixa Econmica Federal DF, SP e RJ - 2014

Ensino Mdio Carreira Administrativa Especialidade Tecnologia da Informao
Edital: http://www.cespe.unb.br/concursos/CAIXA_14_NM
Remunerao: R$2.025,00 30 horas semanais.
Vagas: Cadastro-Reserva.
Valor da Inscrio: R$43,00.
01176992910

INFORMAES SOBRE O CURSO
8 Engenharia de Software. Noes sobre: Modelagem de processos, Ciclo de vida do software. Metodologias de desenvolvimento
de software. Processo unificado: disciplinas, fases, papis e atividades. Metodologias geis. Anlise e projeto orientados a objetos.
UML: viso geral, modelos e diagramas. Padres de projeto. Arquitetura em trs camadas. Arquitetura orientada a servios. Mtricas
e estimativas de software. Anlise por pontos de funo. Conceitos bsicos e aplicaes. 9 Engenharia de requisitos. Conceitos
bsicos. Noes sobre: tcnicas de elicitao de requisitos, especificao de requisitos e tcnicas de validao de requisitos.
Prototipao. 11 Testes de software: conceitos e aplicaes. 11.1 Testes unitrios, de integrao e de aceitao: conceitos e aplicaes.
11.2 Desenvolvimento orientado a testes: conceitos e aplicaes. 12 Gerncia de configurao: conceitos e prticas. 12.1 Uso de
ferramentas de gerncia de configurao. 12.2 Controle de defeitos: conceitos e prticas. 14 Portais corporativos: arquitetura da
informao, portlets e RSS. Ferramentas de Gesto de Contedos. Modelo de Acessibilidade do Governo Eletrnico.
O curso que eu proponho abranger todo o contedo, entretanto impossvel e invivel

esgotar cada ponto do edital em uma aula online. Logo, nosso objetivo ter uma viso
geral sobre todo contedo e direcion-los da melhor forma possvel. Porm, vocs podem
ficar tranquilos! Vou passar para vocs que tem maior probabilidade de cair na prova.
Alm disso, o cronograma ser seguido com a maior fidelidade possvel, entretanto no
esttico e poder haver alteraes no decorrer do curso principalmente inverses de
aulas. Eventualmente, posso tirar o contedo de uma aula e colocar em outro de forma
que o estudo de vocs fique mais lgico e fcil de acompanhar.
No mais, buscarei utilizar questes das principais bancas, exceto quando no existirem.
Nesse caso, posso eventualmente inventar questes. Por fim, caso haja alguma dvida,
reclamao, sugesto, comentrios, erros de digitao, etc, podem enviar para o frum ou
para diego@estrategiaconcursos.com.br. Agora vamos ao cronograma! :-)
01176992910

CRONOGRAMA DO CURSO
Aula Data Tpicos do Edital

31/01 - Aula Demonstrativa
/02 - Engenharia de software. Noes sobre: Modelagem de processos, Ciclo de vida do

software. Metodologias de desenvolvimento de software. Processo unificado: disciplinas,
fases, papis e atividades. Metodologias geis.
/02 - Anlise e projeto orientados a objetos. UML: viso geral, modelos e diagramas.
Arquitetura em trs camadas. Mtricas e estimativas de software.
/02 - Padres de projeto.
2 2 - Anlise por pontos de funo. Conceitos bsicos e aplicaes.
2 - Engenharia de requisitos. Conceitos bsicos. Noes sobre: tcnicas de elicitao de

requisitos, especificao de requisitos e tcnicas de validao de requisitos. Prototipao.
06/02 - Testes de software: conceitos e aplicaes. Testes unitrios, de integrao e de

aceitao: conceitos e aplicaes. Desenvolvimento orientado a testes: conceitos e
aplicaes.
3 - Interoperabilidade de sistemas, SOA e Web Services, Padres XML, XSLT, UDDI, WSDL
e SOAP.
3 - Portais corporativos: arquitetura da informao, Portlets e RSS. Ferramentas de Gesto

de Contedos. Modelo de Acessibilidade do Governo Eletrnico.
3 - Gerncia de configurao: conceitos e prticas. Uso de ferramentas de gerncia de

configurao. Controle de defeitos: conceitos e prticas.
01176992910
e fim...! Porque a prova dia 23/03!

SOBRE AS AULAS
Pessoal, algumas informaes sobre as aulas intercaladas com dicas sobre concursos que
eu acumulei aps diversas provas de concursos.
Pargrafos pequenos: observem que os pargrafos tm, no mximo, quatro linhas. Isso
serve para que a leitura no fique cansativa e para que vocs no desanimem! Para tal,
tento dividir as disciplinas de maneira que as aulas fiquem objetivas e pequenas (exceto
quando h muitos exerccios).
Viso Geral: no se atenham a detalhes antes de entender o bsico. Por que? Ora, no
h nada mais irritante do que ir para uma prova que vai cair, por exemplo, RUP, saber
vrios detalhes, mas no saber as fases e disciplinas. Portanto, caso estejam iniciando os
estudos sobre uma matria, foquem em saber o bsico para depois se especializarem.
Destaques em vermelho: quase todos os pargrafos possuem alguma palavra ou frase

destacada em negrito e em vermelho. Isso ocorre por suas razes: primeiro, para enfatizar
alguma informao importante; segundo, para facilitar a leitura vertical, i.e., aps uma
primeira leitura, a segunda pode ser passando apenas pelos pontos em destaque.
4 Faam muitos exerccios: ler vrias bibliografias muito trabalhoso e, geralmente, no

vale o custo-benefcio. Acredito que o que funciona mesmo entender o bsico, depois
fazer muitos exerccios e, eventualmente, caso encontrarem algo que eu no souberem,
pesquisem-no separadamente. Alm disso, voc vai pegando as manhas da banca.
Linguagem natural: essa uma aula para ser lida, o que por si s j pode ser cansativo.
Tentarei colocar a linguagem mais coloquial possvel, simulando uma conversa. Portanto,
caso virem frases ou palavras em itlico, ou uma palavra estrangeira ou a simulao de
uma conversa com vocs. Pode dar um exemplo, professor? Acabei de dar! :-)
01176992910
6 Faam resumos: essa dica somente serve caso vocs tenham disponibilidade. Caso haja
pouco tempo para estudar ou pouco tempo at a prova, no compensa! Se no, faam
resumos organizados, pois eles economizaro um bom tempo de estudo em suas prximas
provas e sempre que descobrirem novas informaes, insiram-nas no resumo.
7 Diversas figuras: essas aulas estaro em constante evoluo, sempre procura de

explicar as matrias de maneira mais compreensvel e com novas informaes/questes.
Para tal, na minha opinio, fundamental a utilizao de figuras, grficos, painis, etc. Em
minha experincia, bem mais fcil memorizar a partir de imagens.

8 Revisem antes da prova: no adianta querer estudar coisas novas at o ltimo minuto
antes da prova e no revisar o que estudou h um ms. Vocs iro esquecer e iro se irritar
na hora da prova por no lembrarem de conceitos simples. Tirem uma semana para revisar
seus resumos, decorarem algumas coisas e, certamente, iro mais confiantes para a prova.
Bem, pessoal! isso... sejam bem vindos! Espero que vocs curtam e que tenham uma
leitura leve e despojada da aula, mas com muito foco e ateno. Qualquer dvida, podem
entrar em contato comigo; ficarei feliz em ajud-los. Bons estudos, estou torcendo por
vocs! :)
01176992910

8 Engenharia de Software. Noes sobre: Modelagem de processos, Ciclo de vida do software. Metodologias de desenvolvimento de
software. Processo unificado: disciplinas, fases, papis e atividades. Metodologias geis. Anlise e projeto orientados a objetos. UML:
viso geral, modelos e diagramas. Padres de projeto. Arquitetura em trs camadas. Arquitetura orientada a servios. Mtricas e
estimativas de software. Anlise por pontos de funo. Conceitos bsicos e aplicaes. 9 Engenharia de requisitos. Conceitos bsicos.
Noes sobre: tcnicas de elicitao de requisitos, especificao de requisitos e tcnicas de validao de requisitos. Prototipao. 11
Testes de software: conceitos e aplicaes. 11.1 Testes unitrios, de integrao e de aceitao: conceitos e aplicaes. 11.2
Desenvolvimento orientado a testes: conceitos e aplicaes. 12 Gerncia de configurao: conceitos e prticas. 12.1 Uso de
ferramentas de gerncia de configurao. 12.2 Controle de defeitos: conceitos e prticas. 14 Portais corporativos: arquitetura da
informao, portlets e RSS. Ferramentas de Gesto de Contedos. Modelo de Acessibilidade do Governo Eletrnico.
CICLO DE VIDA E METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE
Modelo de Ciclo de Vida definido como uma representao abstrata e simplificada do Processo
de Desenvolvimento de Software, apresentada a partir de uma perspectiva especfica. E o que
esse Processo de Desenvolvimento de Software? Um conjunto de atividades, cuja meta o
desenvolvimento ou a evoluo de um software.
O processo de desenvolvimento de software refere-se a todas as atividades, relacionamentos,

artefatos, ferramentas, papis, etc necessrias para construir, entregar e manter um produto de
software. J o modelo de ciclo de vida apresenta uma representao alto nvel do processo de
software executado.
01176992910
Figura 1 - Principais Modelos de Ciclo de Vida.
Normalmente, ciclos de vida determinam as fases e o relacionamento entre as fases. Os modelos

de processo de software, diferentemente do ciclo de vida, representam processo de software

executado ou como deveria ser executado em um nvel de abstrao mais aprofundado que o do
ciclo de vida (Ateno: comum as provas tratarem como sinnimos).
Pessoal, coloquei na Figura 1 os principais grupos de modelos de ciclo de vida. Essa classificao
no um consenso entre os autores e nem so mutuamente exclusivas, podendo haver
combinao entre elas. Mas fiquem tranquilos, foquem nos modelos em si e, no, em seus grupos.
Isso apenas para orientao! :-)
01176992910

MODELO EM CASCATA
O primeiro modelo designado Cascata ou Clssico ou Sequencial ou Linear ou Waterfall ou Rgido

ou Monoltico (Todos j caram em prova!). Esse nome devido ao encadeamento de uma fase
com a outra. Os estgios do modelo demonstram as principais atividades de desenvolvimento.
Observem a Figura 2:
No Modelo em Cascata, uma fase s se inicia aps o trmino e aprovao da fase anterior, isto ,
h uma sequncia de desenvolvimento do projeto. Por exemplo, a Fase 4 s iniciada aps o
trmino e aprovao da Fase 3. A Fase 5 s iniciada aps o trmino e aprovao da Fase 4. Mas
que fases so essas? Bem, agora que complica, porque cada autor resolve criar suas fases! Vejamos:
01176992910
Figura 2 - Modelo em Cascata Genrico.
Por Sommerville Por Yourdon Por Pressman

1. Definio de Requisitos 1. Requisitos de Sistema 1. Comunicao
2. Projeto de Sistema e Software 2. Requisitos de Software 2. Planejamento
3. Implementao e Teste de Unidade 3. Anlise 3. Modelagem
4. Integrao e Teste de Sistema 4. Projeto 4. Construo
5. Operao e Manuteno 5. Codificao 5. Implantao
6. Teste
7. Operao

Percebam que h diferenas gritantes entre os autores! Inclusive, h divergncias at entre autor e
ele mesmo, dependendo da verso do livro (Exemplo: Pressman mudou as fases na ltima edio
de seu livro). Professor, voc j viu isso cair em prova? Sim, j vi! E o que aconteceu? Bem, polmica,
recursos, etc!
Na prtica, esses estgios se sobrepem e trocam informaes entre si Na teoria, o resultado de

cada fase consiste de um ou mais documentos aprovados. Por exemplo: durante o projeto, so
identificados problemas com requisitos; durante a codificao, so encontrados problemas de
projeto e assim por diante. De modo geral, grande parte dos modelos possuem as seguintes fases:
Planejamento: faz-se o esboo do escopo e dos requisitos, alm de estimativas razoveis

sobre recursos, custos e prazos.
Anlise e Especificao de Requisitos: durante essa fase, refina-se os requisitos e o escopo

e desenha-se o problema em questo.
Projeto: durante essa fase, incorpora-se requisitos tecnolgicos aos requisitos essenciais do
sistema e projeta-se a arquitetura do sistema.
Implementao: durante essa fase, codifica-se o software como um conjunto de programas

executveis pela mquina.
Teste: o programa testado como um sistema completo para garantir que os requisitos de
software foram atendidos.
Implantao, Operao e Manuteno: o sistema de software liberado para o cliente,

treina-se usurios, gerencia servios e realiza manutenes.
Vantagens Desvantagens
simples e fcil de aplicar, facilitando o planejamento. Diviso inflexvel do projeto em estgios distintos.
Fixa pontos especficos para a entrega de artefatos. Dificuldade em incorporar mudanas de requisitos.
Funciona bem para equipes tecnicamente fracas. Clientes s visualizam resultados prximos ao final do
01176992910
projeto.
Pressupe que os requisitos ficaro estveis ao longo do Atrasa a reduo de riscos.
tempo.
Realiza documentao extensa por cada fase ou estgio. Apenas a fase final produz um artefato entregvel.
Possibilita boa aderncia a outros modelos de processo. Cliente deve saber todos os requisitos no incio do
projeto.
No fornece feedback entre as fases.
Professor, o que quer dizer atrasar a reduo de riscos? Bem, essa uma desvantagem recorrente
em provas. Como uma fase s se inicia aps o trmino da fase anterior, s possvel verificar se
houve erros nas ltimas fases como pode ser visto na Figura 3. Em outros modelos, os riscos so
reduzidos desde as primeiras fases.

Figura 3 - Progresso do Projeto no Modelo em Cascata.
Percebam que os riscos deveriam ser descobertos no incio, porm eles so descobertos somente
aps a integrao. Voc podem notar que, nesse instante (parte vermelha), o progresso do projeto
avana e retrai diversas vezes, porque os requisitos esto sendo modificados ou porque erros esto
sendo corrigidos.
Notem, tambm, que o projeto no terminou em seu deadline original. Como a reduo dos riscos
atrasou, todo andamento do projeto tambm atrasou. Dessa forma, no se cumpriu nem o prazo
do projeto e, provavelmente, nem o oramento tendo em vista que, quanto mais ao fim do
projeto, mais caras as modificaes.
A grande vantagem do Modelo em Cascata que, antes o software era feito artesanalmente e
agora dividido em fases distintas, padronizadas, etc. possvel colocar pessoas com perfis
especficos para cada fase, i.e., quem tem facilidade de se comunicar vai ser analista de requisitos,
programadores vo fazer a codificao, etc.
A grande desvantagem que - em projetos complexos demora-se muito para chegar at a fase
de testes, sendo que o cliente no v nada rodando at a implantao. Ento, pode acontecer de,
nas fases finais, os requisitos da organizao no serem mais os mesmos e o software no ter mais
01176992910
utilidade para organizao.
Professor, ento o Modelo em Cascata no deve ser usado em nenhuma hiptese? No, ele pode
ser usado! No entanto, preferencialmente quando os requisitos forem bem compreendidos e
houver pouca probabilidade de mudanas radicais durante o desenvolvimento do sistema. Vocs
entenderam?

MTODOS FORMAIS
Agora vamos falar sobre os modelos especficos! Professor, por que esse nome? Bem, s para
agrupar modelos que no se encaixam diretamente em outros grupos. Comecemos pelos Mtodos
Formais, termo usado para indicar atividades que contem com representaes matemticas de
software, especificao formal, prova de especificao, desenvolvimento transformacional, etc.
Esse modelo utilizado em ambientes extremamente complexos. So lentos e dispendiosos, alm

de exigirem treinamento extensivo. So utilizados para o desenvolvimento de sistemas que
necessitam de grande robustez e confiabilidade diante da possibilidade de perda de vidas ou srio
prejuzo, caso haja falhas.
Os chamados mtodos formais de desenvolvimento de software no so amplamente usados no

desenvolvimento de software industrial. A maioria das empresas de desenvolvimento de software
no os considera adequados quanto ao custo para aplica-los em seus processos de
desenvolvimento de software.
Contudo, a especificao formal uma excelente maneira para descobrir erros de especificao e
apresentar a especificao do sistema de modo no ambguo. As poucas organizaes que tm
feito investimentos em mtodos formais tm constatado menos erros no software entregue, sem
aumento de custos.
Os mtodos formais podem ser adequados em termos de custo caso seu uso seja limitado a partes
do ncleo do sistema e caso as empresas desejem fazer alto investimento inicial nessa tecnologia.
Professor, pode dar um exemplo de mtodo formal? Sim, o Mtodo Cleanroom, que trata o
desenvolvimento semelhante a uma sala limpa de cirurgia.
01176992910

ORIENTADO A ASPECTOS
A Programao Orientada a Aspectos (POA) uma metodologia de desenvolvimento de software

que separa responsabilidades, requisitos e interesses (Concerns) de um sistema. A modularizao
dos aspectos produz uma arquitetura fcil de projetar, implementar e manter. Muitos acham que
esse paradigma veio para substituir a Programao Orientada a Objetos (POO). Est certo?
No! POA no veio substituir a POO, mas complement-la (utiliz-la isoladamente no traz
benefcios para o projeto). Para tal, ela mantm o foco na separao de interesses (Separation of
Concerns), que so requisitos especficos que devem ser atendidos para satisfazer o objetivo de
um sistema, mas que no pertencem ao domnio do negcio. H dois tipos:
Interesses Principais (Core Concerns): capturam as funcionalidades centrais de um mdulo.

Interesses Ortogonais (Crosscutting Concerns): capturam funcionalidades perifricas.
Por que separar interesses? Porque gera cdigo de melhor qualidade; maior modularidade; facilita
atribuio de responsabilidade entre mdulos; promove a reusabilidade; facilita a evoluo de
software; viabiliza a anlise do problema dentro de domnios especficos; entre outras tantas
vantagens.
Ok, mas o que so Aspectos? So propriedades de um sistema envolvendo diversos componentes

funcionais que no podem ser expressas utilizando as notaes e linguagens atuais de uma maneira
bem localizada (Exemplo: sincronizao, interao entre componentes, distribuio, persistncia).
Os interesses so carregados em um mdulo chamado Aspecto.
01176992910

BASEADO EM COMPONENTES
Pessoal, vocs j pararam para pensar por que a disciplina Engenharia de Software se chama
Engenharia de Software? Bem, esse conceito surgiu em 1968, em uma conferncia
organizada para discutir a Crise do Software. Essa crise foi o resultado da introduo de
circuitos integrados em computadores. E isso era ruim, professor?
No, pelo contrrio! Desde o ingresso dos circuitos integrados,

tornou-se possvel e vivel fazer aplicaes extremamente
complexas. No entanto, o desenvolvimento de software era bastante
informal e incipiente, criando softwares, cujo custo superava as
previses, no confiveis, difceis de manter e de desempenho
insatisfatrio.
Naquela poca, os custos de hardware estavam caindo, enquanto os custos de software

aumentavam rapidamente. Novas tcnicas e mtodos eram necessrios para controlar a
complexidade inerente aos grandes sistemas de software. Agora eu volto a perguntar: por que
Engenharia de Software se chama Engenharia de Software?
Porque foi uma tentativa de contornar a crise ao utilizar slidos princpios de engenharia a fim de
obter software de maneira econmica, que seja confivel e que trabalhe em mquinas reais, dando
um tratamento mais sistemtico e controlado (comum Engenharia) ao desenvolvimento de
sistemas de software complexos.
Pessoal, pensem comigo: a engenharia evolui seus mtodos h centenas de anos, enquanto o
desenvolvimento de software bastante recente! Logo, faz sentido utilizar os conceitos
consolidados de engenharia para melhorar seus processos de desenvolvimento de software. No
acham?
Ok, professor. Mas o que isso tem a ver com reso de componentes? Ora, a Engenharia
especializada em produzir componentes reusveis. Engenheiros raramente fabricam um
01176992910
componente a partir do nada. Eles baseiam seus projetos em componentes exaustivamente

testados em outros sistemas.
Quando se fala em Processos Orientados a Reso, refere-se a uma estratgia de engenharia de

software na qual o processo de desenvolvimento voltado ao reso do software existente. E qual
a vantagem disso? Isso resulta em reduo de custos de produo e manuteno, entregas mais
rpidas e aumento de qualidade.
Nos ltimos anos, uma abordagem para desenvolvimento de software denominada Component-
Based Software Engineering (CBSE) tem utilizado o reso como fundamento principal. Essa
abordagem dependente de uma grande base de componentes reusveis e algum framework de
integrao desses componentes.

Figura 4 - Engenharia de Software baseada em Componentes.
O Modelo Genrico de Engenharia de Software Baseada em Componentes (Figura 4):
Especificao de Requisitos: tem o objetivo de traduzir as informaes coletadas durante a

atividade de anlise em um documento que define um conjunto de requisitos. Devem ser
includos dois tipos de requisitos nesse documento. Requisitos de Usurio e Requisitos de
Sistema.
Anlise de Componentes: nesta fase, feita uma busca pelos componentes para implementar
essa especificao. Geralmente, no existe uma correspondncia exata entre o componente
encontrado e o procurado. Muitas vezes, os componentes que podem ser usados fornecem
apenas parte da funcionalidade necessria.
Modificao de Requisitos: os requisitos so analisados usando as informaes sobre os

componentes encontrados, que so modificados para refletir os componentes disponveis.
Quando as modificaes so impossveis, a atividade de anlise de componentes pode ser
novamente realizada para procurar alternativas.
Projeto de Sistema com Reso: o framework do sistema projetado ou um framework existente

01176992910
reusada. Os projetistas levam em considerao os componentes reusados. Pode ser

necessrio projetar algum software novo caso os componentes reusveis no estejam
disponveis.
Desenvolvimento e Integrao: software que no pode ser adquirido externamente

desenvolvido e os componentes e os sistemas COTS so integrados para criar o novos sistema.
A integrao de sistema, neste modelo, pode ser parte do processo de desenvolvimento, em
vez de ser uma atividade separada.
Validao de Sistema: processo de verificao de se um sistema atende s necessidades e

expectativas do cliente. Professor, o que so Sistemas COTS? Esse o acrnimo de Commercial
Off-The-Shelf, que um conjunto de solues pr-fabricadas e disponveis no mercado,
podendo ser compradas ou licenciadas, i.e., uma grande biblioteca de componentes prontos.

MODELOS EVOLUCIONRIOS
Antes de comear, acho oportuno explicar porque a Figura 1 apresenta o modelo evolucionrio
como um tipo de modelo iterativo. Pressman diz: modelos evolucionrios so iterativos,
apresentando caractersticas que possibilitam desenvolver verses cada vez mais completas do
software.
Ok, o tema agora Modelos Evolucionrios! Esse modelo baseia-se na ideia de desenvolvimento
de uma implementao inicial, expondo o resultado aos comentrios do usurio e refinando esse
resultado por meio de vrias verses at que seja desenvolvido um sistema adequado. Existem dois
tipos fundamentais de desenvolvimento evolucionrio:
Desenvolvimento Exploratrio: comea com as partes do sistema compreendidas e evolui

por meio da adio de novas caractersticas propostas pelo cliente at entregar o sistema
final.
Prototipao Throwaway: tambm conhecida como descartvel, tem o intuito de

compreender os requisitos do cliente e, a partir disso, desenvolver melhor definio de
requisitos para o sistema.
Em geral, a abordagem evolucionria mais eficaz que abordagem em cascata. Por que? Porque
a especificao pode ser desenvolvida de forma incremental. medida que os usurios
compreendem melhor seu problema, isso pode ser refletido no sistema de software. Essa
abordagem possui dois problemas (inclusive, j caram no Senado Federal):
O processo no visvel: se os sistemas so desenvolvidos rapidamente, no vivel

economicamente produzir documentos para cada verso do sistema.
Os sistemas so frequentemente mal estruturados: mudanas contnuas tendem a

corromper a estrutura do software e tornar mudanas difceis e caras.
O Pressman recomenda o Desenvolvimento Evolucionrio para sistemas de pequeno e mdio porte

01176992910
(at 500 mil linhas de cdigo). J para sistemas maiores e mais complexos, esses problemas
supracitados tornam-se mais graves. difcil estabelecer uma arquitetura estvel, tornando difcil
integrar as contribuies das equipes.
Vamos resumir? um modelo que apresenta uma verso inicial aos usurios, com os requisitos
mais bem compreendidos, para refinamento do resultado verso a verso. Pode ser Evolucionrio
(quando evolui at o sistema final) ou Throwaway (quando descartado). Ademais, recomendado
para sistemas de pequeno e mdio porte.

Figura 5 - Desenvolvimento Evolucionrio.
Um esboo simples do processo de desenvolvimento evolucionrio apresentado na Figura 5. As

atividades de especificao, desenvolvimento e validao so intercaladas, em vez de separadas,
com feedback rpido que permeia as atividades. H dois modelos principais de desenvolvimento
evolucionrio: Prototipagem e Espiral.
01176992910

MODELOS DE PROTOTIPAGEM
A Prototipagem utilizada quando no se conhece bem os requisitos. uma forma de entend-

los melhor para posteriormente desenvolver o software. Configura um processo interativo e rpido
de desenvolvimento e o prottipo serve como um mecanismo de identificao dos requisitos do
software.
Um prottipo uma verso inicial de um sistema de software usado para demonstrar conceitos,
experimentar opes de projeto e, geralmente, conhecer mais sobre o problema e suas possveis
solues. Assim, os custos so controlados e os stakeholders do sistema podem experimentar o
prottipo mais cedo no processo.
Um prottipo de software pode ser usado em um processo de desenvolvimento de software de

vrias maneiras! Veremos trs modos possveis de utilizao (Ateno: quando a questo no
especifica o tipo de prototipao, geralmente se trata de prototipao descartvel e, no,
evolucionria):
a) No processo de engenharia de requisitos, um prottipo pode ajudar na descoberta e

validao dos requisitos do sistema.
b) Processo de projeto do sistema, um prottipo pode ser usado para explorar solues
especficas de software e apoiar o projeto de interface com o usurio.
c) No processo de teste, um prottipo pode ser usado para realizar testes completos com o
sistema que ser entregue para o cliente.
Na Prototipao Descartvel, inicia-se pelos requisitos mais difceis e menos compreendidos e

recomendvel para programas grandes e complexos. Na Prototipao Evolucionria inicia-se pelos
requisitos mais fceis e mais bem compreendidos e recomendvel para programas pequenos ou
mdios.
Prottipos permitem que os usurios introduzam novas ideias para os requisitos e encontrem
01176992910
pontos fortes e fracos no software. Ademais, prottipos podem revelar erros e omisses nos
requisitos propostos, alm de reduzirem o tempo de desenvolvimento, treinamento e
documentao o sistema.
Professor, s h vantagens? No, h desvantagens tambm: anlise insuficiente, devido a

desenvolvedores que se focam somente no prottipo e esquecem de analisar o problema global;
usurios confundem prottipo com o sistema final, sendo que eles sero descartados
posteriormente; documentao pode ser prejudicada.
H tambm a falta de visibilidade do progresso, quando o sistema evolui constantemente, mas

nunca termina; tempo excessivo para desenvolver o prottipo, sendo que prottipos devem ser

feitos, em teoria, rapidamente; e altos custos de implementao de prottipos, quando no h
planejamento adequado. Por fim, vamos ver como o processo genrico de desenvolvimento:
Figura 6 - Processo de Desenvolvimento de Prottipos.
01176992910

MODELO EM ESPIRAL
Agora vamos analisar o Modelo em Espiral. Ele foi proposto originalmente, em 1988, por Boehm.
Sua ideia era, em vez de representar o processo de software como uma sequncia de atividades
com algum retorno entre uma atividade e outra, o processo deveria ser representado como uma
espiral.
Figura 7 - Modelo em Espiral (Boehm).
conhecido como prototipagem-em-etapas, por combinar o modelo em cascata com a

prototipao. Cada loop representa uma fase do processo de software. Dessa forma, o loop mais
interno pode estar relacionado viabilidade do sistema; o prximo loop, definio de requisitos;
o prximo, ao projeto de sistema e assim por diante. Esses loops so divididos em quatro atividades:
Terminar objetivos: definem-se os objetivos e restries e identificam-se os riscos de

projeto.
Identificao e resoluo de riscos: realiza-se uma anlise detalhada de cada risco e

01176992910
providncias so tomadas para reduzi-los.
Desenvolvimento e testes: seleciona-se um modelo de desenvolvimento para o sistema (Ex:

prototipao evolucionria, mtodos formais, etc).
Planejamento: revisa-se o projeto e decide-se sobre o prosseguimento ao prximo loop da

espiral, realizando o planejamento.
IMPORTANTE
Cada loop na espiral representa uma fase no processo, entretanto essas fases no so fixas, i.e., escolhem-se quais
fases se deseja realizar.

Figura 8 - Modelo em Espiral (Pressman).
Vocs entenderam isso? O Pressman explica isso por meio da Figura 8! Percebam que o loop mais
interno trata do projeto de desenvolvimento de conceito, o segundo loop trata do projeto de
desenvolvimento de produto, o terceiro trata do projeto de melhoria e o ltimo, mais claro, trata
do projeto de manuteno.
Quero enfatizar isso! Cada loop uma fase e a fase escolhida de acordo com as necessidades
do negcio! J as atividades do processo so fixas para todos os loops. No entanto, Boehm utiliza
uma diviso de atividades diferente do Pressman. No caso de dvida, considerem a verso original
do Modelo de Boehm.
Alm disso, ao final de cada loop, h uma tomada de deciso a respeito do projeto. Vocs
perceberam, pela Figura 8, que existem prottipos que so utilizados para verificar a viabilidade do
01176992910
projeto. Ao final de cada loop na espiral, deve-se decidir se o projeto continuar ou se ser
interrompido.
Pessoal, por que esse modelo se destaca em relao aos outros? Porque ele enfatiza bastante um
aspecto: gerenciamento de riscos. Este um modelo complexo que precisa ser gerenciado por
pessoas que tenham grande experincia na avaliao de riscos. Geralmente, o modelo utilizado
em sistemas crticos e grandes!
Suporta mecanismos de reduo de riscos. Exige analistas de risco bastante experientes.
Obtm-se verses do sistema a cada iterao. Exige uma equipe de desenvolvimento extremamente
qualificada.

Entregando produtos cada vez mais refinados e de Exige um gerenciamento de processo mais complexo.
melhor qualidade.
Reflete as prticas reais de engenharia atual. No recomendado resolver problemas mais simples e
pequenos.
Apresenta uma abordagem sistemtica.
Apresenta estimativas realsticas.
01176992910

MODELOS ITERATIVOS E INCREMENTAIS
Como foi dito anteriormente, o modelo em cascata acumulava riscos e vrios projetos comearam
a fracassar ao utiliz-lo. Ento surgiu o modelo iterativo como uma tentativa de resolver esse
problema. Vejamos a diferena entre o modelo em cascata e o modelo iterativo:
No Modelo em Cascata, caso haja cem requisitos, analisa-se os cem requisitos, projeta-se
os cem requisitos, codifica-se os cem requisitos, testa-se os cem requisitos, e assim, por
diante, sequencialmente.
No Modelo Incremental, caso haja cem requisitos no projeto, divide-se os cem requisitos
em vinte miniprojetos de cinco requisitos e utiliza-se o modelo em cascata para cada
miniprojeto.
Pode-se combinar a abordagem incremental com uma abordagem iterativa para desenvolver os
miniprojetos em paralelo e entregar partes diferentes do projeto. A Figura 9 apresenta os
miniprojetos de cinco requisitos sendo feitos iterativa e paralelamente em um modelo iterativo e
incremental.
01176992910
Figura 9 - Modelo Iterativo e Incremental.
Assim, os resultados so mais rpidos, h maior interao com o usurio e h um feedback mais
intenso. Essa abordagem permite gerenciamento e mitigao de riscos. Professor, mas eu fiquei
com uma dvida: qual a diferena entre Modelo Iterativo e Modelo Incremental? Ou eles so
exatamente a mesma coisa?

IMPORTANTE
Galera, j vi essas palavras serem trocadas dezenas de vezes. No entanto, muitas vezes a prpria banca erra e, s
vezes, no volta atrs! Infelizmente isso acontece =(
Iterativo: reiterado ou repetitivo.

Interativo: participao ou ao mtua.
Bem, galera... muito muito muito raro cobrarem a diferena entre modelo iterativo e modelo
incremental! Na verdade, quando se fala em modelo iterativo, presume-se que incremental e
quando se fala em modelo incremental, presume-se que iterativo. Eles frequentemente andam
lado a lado, mas h pequenas diferenas.
Professor, mas e se cair em prova? Ora, caso caia em prova, a diferena que, no modelo iterativo,
h vrias equipes desenvolvendo uma parte do software a serem integradas e, no modelo
incremental, lana-se a verso 1.0, adiciona funcionalidades, lana uma verso 2.0, adiciona mais
funcionalidades e assim por diante.
Modelo Incremental: observem que a imagem mostra um artista com uma ideia completa sobre o
quadro, mas ele desenvolve cada parte separadamente at integrar as partes em uma imagem
completa. como se fosse um quebra-cabeas em que cada parte entregue funcionando e
depois integrada. Produz builds, i.e., partes do software.
01176992910
Modelo Iterativo: observem que a imagem mostra um artista com um esboo do quadro, sendo
que ele desenvolve vrias verses do quadro at chegar ao resultado final. como se fosse uma
viso abstrata da imagem, que em seguida Produz releases, i.e., verses constantemente
melhoradas da imagem.
Uma das vantagens do modelo iterativo e incremental que o cliente pode receber e avaliar as
entregas do produto mais cedo, j no incio do projeto. Alm disso, h maior tolerncia a mudanas
com consequncia direta de reduo do risco de falha do projeto, i.e., ele acomoda melhor
mudanas. Ele aumenta o reso e a qualidade.

RAPID APPLICATION DEVELOPMENT (RAD)
O RAD um modelo iterativo e incremental, que enfatiza o ciclo de desenvolvimento curto (60 a
90 dias). Esse desenvolvimento ocorre to rpido, porque utilizada o reso de componentes a
exausto. Como muitos componentes j esto testados, pode-se reduzir o tempo total de
desenvolvimento. As fases so:
01176992910
Figura 10 - Fases do RAD.
Modelagem de Negcio: o fluxo de informaes entre as funes de negcio modelado

de modo a responder que informao direciona o processo de negcio; que informao
gerada; quem gera essa informao; para onde vai a informao gerada; e, por fim, quem
processa a informao.
Modelagem de Dados: o fluxo de informao definido na fase de modelagem de negcio

refinado em um conjunto de objetos de dados que so necessrios para suportar o
negcio. Os atributos de cada objeto so identificados e os relacionamentos entre esses
objetos so definidos.

Modelagem de Processo: os objetos de dados definidos na modelagem de dados so
transformados para conseguir o fluxo necessrio para implementar uma funo do negcio.
Descries do processamento so criadas para adicionar, modificar, descartar ou recuperar
um objeto de dados.
Gerao da Aplicao: considera o uso de tcnicas de quarta gerao, trabalha com a

reutilizao de componentes de programa existentes quando possvel, ou cria
componentes reusveis. So usadas ferramentas automatizadas para facilitar a construo
do software.
Teste e Modificao: como o processo enfatiza o reso, muitos componentes j esto

testados e isso reduz o tempo total de teste. No entanto, os novos componentes devem
ser testados e todas as interfaces devem ser exaustivamente exercitadas para colocar o
resultado em produo.
Neste modelo, h uma interao direta e intensa com o usurio e uso frequente de programao
de banco de dados e ferramentas de apoio ao desenvolvimento, como geradores de telas e
relatrios. Um modelo como este no pode ser utilizado em qualquer situao. Recomenda-se
us-lo quando:
a aplicao no necessita de softwares auxiliares (standalone);

possvel fazer uso de classes pr-existentes;
a performance no o mais importante;
a distribuio do produto no mercado pequena;
o escopo do projeto restrito;
o sistema pode ser dividido em vrios mdulos;
o risco de mudana tecnolgica baixo.
Permite o desenvolvimento rpido e/ou a prototipagem Exige recursos humanos caros e experientes.
de aplicaes.
Criao e reutilizao de componentes. O envolvimento com o usurio tem que ser ativo.
Desenvolvimento conduzido em um nvel mais alto de Comprometimento da equipe do projeto.

abstrao. 01176992910
Grande reduo de codificao manual com wizards. Custo alto do conjunto de ferramentas e hardware para
rodar a aplicao;
Cada funo pode ser direcionada para a uma equipe Mais difcil de acompanhar o projeto.
separada.
Maior flexibilidade (desenvolvedores podem reprojetar Perda de preciso cientfica (pela falta de mtodos
vontade). formais).
Provvel custo reduzido (tempo dinheiro e tambm Pode levar ao retorno das prticas caticas no
devido ao reuso). desenvolvimento.
Tempo de desenvolvimento curto. Pode construir funes desnecessrias.
Prottipos permitem uma visualizao mais cedo. Requisitos podem no se encaixar (conflitos entre
desenvolvedores e clientes).
Envolvimento maior do usurio. Padronizao (aparncia diferente entre os mdulos e
componentes)

RATIONAL UNIFIED PROCESS (RUP)
O RUP um framework iterativo e incremental de desenvolvimento de software, centrado na

arquitetura, planejado por riscos, guiado por casos de uso e orientado a objetos, criado pela
Rational, empresa adquirida pela IBM. Ele se originou a partir de uma tentativa de acabar com uma
srie de problemas frequentes:
Necessidades no eram atendidas: por conta de falhas na verificao e validao, os

requisitos no atendiam as necessidades do negcio e do usurio.
Requisitos muito volteis e instveis: partia-se do princpio de que os requisitos no se

modificariam ao longo do desenvolvimento do projeto.
Mdulos no se integravam: projeto era modularizado, dividido entre equipes, entretanto

ocorriam diversas falhas no momento de integr-los.
Dificuldades de manuteno: no havia assistncia tcnica nem padronizao para escrita

do software, prejudicando a manuteno.
Descoberta tardia de problemas: requisitos eram entendidos de maneira errada, no eram

validados e causavam altos prejuzos quando descobertos.
Qualidade ou experincia pobre dos usurios: a validao dos requisitos era feita por
usurios dispensveis da organizao, geralmente inexperientes.
Performance de carga sofrvel: a aplicao satisfaz todos os requisitos, no entanto tem uma
performance sofrvel.
Esforo descoordenado da equipe: falta de coordenao adequada implica em retrabalho

por parte das equipes.
01176992910
IMPORTANTE
Galera, se cair em algum edital ou provas apenas Processo Unificado, podem considerar que se trata do RUP!
O RUP oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades
dentro de uma organizao de desenvolvimento. Sua meta garantir a produo de software de
alta qualidade que atenda s necessidades dos usurios dentro de um cronograma e de um
oramento previsveis.
Os modelos convencionais de processo apresentam uma viso nica de processo. Por outro lado,
o RUP geralmente descrito a partir de trs perspectivas:

Dinmica: mostra as fases do modelo ao longo do tempo.
Esttica: mostra as atividades realizadas no processo.
Prtica: sugere boas prticas a serem usadas no processo.
A maior parte das descries do RUP tenta combinar as perspectivas esttica e dinmica em um
nico diagrama, como mostrado na Figura 11 (Grfico de Baleias):
Figura 11 - Fases e Disciplinas do RUP.
O RUP constitudo por quatro fases discretas no processo de software. No entanto, ao contrrio
do modelo em cascata no qual as fases coincidem com as atividades do processo , as fases do
RUP esto relacionadas mais estritamente aos negcios do que a assuntos tcnicos. Podemos v-
las a seguir:
Iniciao: tem o objetivo de estabelecer um caso de negcio para o sistema. Deve-se identificar
as entidades externas, que iro interagir com o sistema, e definir essas interaes. Depois voc
usa essas informaes para avaliar a contribuio do sistema com o negcio. Se a contribuio
01176992910
for de pouca importncia, o projeto pode ser cancelado depois dessa fase.
Artefatos importantes: Documento de Viso; Casos de Negcio; Plano de Desenvolvimento

do Software; Modelo de Casos de Uso; Glossrio.
Elaborao: tem o objetivo de desenvolver um entendimento do domnio do problema,

estabelecer um framework de arquitetura para o sistema, desenvolver o plano de projeto e
identificar os riscos principais do projeto. Ao concluir, deve-se ter um modelo de requisitos para
o sistema, uma descrio de arquitetura e um plano de desenvolvimento para o software.
Artefatos importantes: Prottipos; Lista de Riscos; Documento de Arquitetura de Software;

Modelo de Projeto; Modelo de Dados.

Construo: tem o objetivo de desenvolver partes do sistema paralelamente e integradas
durante esta fase. Est essencialmente relacionada ao projeto, programao e teste de sistema.
Ao concluir esta fase, voc deve ter um sistema de software em funcionamento e a
documentao associada pronta para ser liberada para os usurios.
Artefatos importantes: o prprio sistema executvel e suas bibliotecas; conjunto de testes

do software;
Transio: tem o objetivo de colocar o sistema em funcionamento no ambiente real de uso. A

fase final do RUP est relacionada transferncia do sistema da comunidade de
desenvolvimento para a comunidade dos usurios. Essa uma atividade onerosa e, s vezes,
problemtica. Ao concluir esta fase, voc dever ter um sistema de software documentado.
Artefatos importantes: Notas de Release; Artefatos de Instalao; Materiais de Treinamento,

entre outros.
Falamos da perspectiva dinmica e agora vamos falar da perspectiva esttica. Ela enfoca as
atividades que ocorrem durante o processo de desenvolvimento. So seis disciplinas principais e
trs disciplinas de apoio ou infraestrutura cuidado para no confundi-las! Podemos v-las a
seguir:
Modelagem de Negcios: os processos de negcios so modelados usando casos de uso de

negcios. Busca entender a estrutura e a dinmica da organizao na qual um sistema deve
ser implantado, alm dos problemas atuais da organizao-alvo e identificar as possibilidades
de melhoria.
Requisitos: os agentes que interagem com o sistema so identificados e os casos de uso so

desenvolvidos para modelar os requisitos. Ele estabelece e mantm concordncia com os
clientes e outros envolvidos sobre o que sistema deve fazer. Ele define fronteiros do sistema e
fornece uma base para clculo de custo e tempo.
Anlise e Projeto: um modelo de projeto criado e documentado usando modelos de

arquitetura, de componente, de objeto e de sequncia. Transforma os requisitos em um projeto
do sistema a ser criado, desenvolvendo uma arquitetura bsica para o sistema e adaptando o
01176992910
projeto ao seu ambiente.
Implementao: os componentes de sistema so implementados e estruturados em

subsistemas de implementao, organizados em camadas. Implementa classes e objetos em
termos de componentes testados e desenvolvidos como unidades. Ademais, integra os
resultados produzidos ao sistema executvel.
Teste: o teste um processo iterativo realizado em conjunto com a implementao. Localiza e

documenta defeitos na qualidade do software, relatando a forma geral da qualidade observada
no software. Valida suposies e funes e verifica se os requisitos foram implementados
adequadamente.

Implantao: uma verso do produto criada, distribuda aos usurios e instalada no local de
trabalho. Garantem que o produto ser disponibilizado aos usurios finais, por meio de uma
instalao personalizada em formato compacto e com acesso correto. Galera, colocar o
sistema em produo.
Gerenciamento de Configurao e Mudanas: este workflow de apoio controla e gerencia as

mudanas do sistema e mantm a integridade entre eles e suas verses. Para realizar essa
tarefa, identificam-se os itens de configurao, definem-se restries de mudana e realizam-
se auditorias, evitando conflitos.
Gerenciamento de Projetos: este workflow de apoio fornece diretrizes prticas para planejar,
montar equipes, executar e monitorar os projetos. Entretanto, no to amplo quanto o
PMBOK, por exemplo. Apesar de incluir gerenciamento de riscos, no contm gerenciamento
de pessoal, oramento e contrato.
Ambiente: este workflow de apoio est relacionado disponibilizao de ferramentas

apropriadas de software para a equipe de desenvolvimento. Ele concentra-se nas atividades
necessrias configurao (tanto de hardware quanto de software) do processo para um
projeto.
Agora vamos falar da perspectiva prtica. Ela descreve boas prticas de engenharia de software
recomendadas para uso em desenvolvimento de sistemas. So elas:
Desenvolvimento Iterativo: um projeto que usa o desenvolvimento iterativo tem um ciclo de

vida que consiste em vrias iteraes, que incorporam um conjunto quase sequencial de
atividades em modelagem de negcios, requisitos, anlise e projeto, implementao, teste e
implantao, dependendo do local em que ela est localizada no ciclo. Este desenvolvimento
gera um build que j pode interagir com o usurios gerando novos e melhores requisitos.
Gerenciamento de Requisitos: condio ou capacidade com a qual o sistema dever estar em

conformidade, isto , uma abordagem sistemtica para levantar e documentar os requisitos e
acompanhar todo o ciclo de vida desse requisito no processo de software. Para tanto, deve-se
estar preocupado com a Verificao e Validao destes. Alguns requisitos dependem de outros,
logo todos devem estar mapeados, para caso haja uma mudana, todos possam ser rastreados.
01176992910
Uso da Arquitetura de Componentes: componentes so grupos de cdigos coesos, na forma

de cdigo fonte ou executvel, com interfaces bem definidas e comportamentos que fornecem
forte encapsulamento do contedo e so, portanto, substituveis. De maneira informal,
componente algo que presta uma funcionalidade sem conhecer seus detalhes de
implementao.
Modelagem Visual (UML): o uso de notaes de design grficas e textuais, semanticamente

ricas, para capturar designs de software. Uma notao, como a UML, permite que o nvel de
abstrao seja aumentado, enquanto mantm sintaxe e semntica rgidas. Assim, a
comunicao na equipe melhora medida que o design formado e revisado, permitindo ao
leitor raciocinar sobre ele e fornecendo uma base no ambgua para a implementao.

Contnua Verificao da Qualidade: garantia da qualidade de software o ponto mais comum
de falha nos projetos de software. O RUP ajuda no planejamento do controle da qualidade e
cuida da sua construo em todo processo, envolvendo todos os membros da equipe.
Nenhuma tarefa especificamente direcionada para a qualidade e o RUP assume que cada
membro da equipe responsvel pela qualidade durante todo o processo.
Gerenciamento de Mudanas: em todos os projetos de software, mudanas so inevitveis. RUP

define mtodos para controlar, rastrear e monitorar estas mudanas. RUP tambm define
espaos de trabalho, garantindo que um sistema de engenharia de software no ser afetado
por mudanas em outros sistemas. Este conceito bem aderente com arquiteturas de software
baseados em componentizao.
Figura 12 - Ciclo de Desenvolvimento.
Em suma, h trs perspectivas: dinmica, esttica e prtica. H cinco disciplinas de engenharia de

software e mais trs disciplinas de apoio/infraestrutura. Uma passagem pelas quatro fases se chama
Ciclo de Desenvolvimento e uma passagem pelas nove disciplinas se chama Iterao, podendo
haver mais de uma iterao por fase.
01176992910
Figura 13 - Disciplinas do RUP.

Vamos falar agora dos marcos de cada fase. Um marco um ponto final reconhecvel de uma
atividade do processo de software. A cada marco, deve existir uma sada formal e deve representar
o fim de um estgio lgico e distinto do projeto. Para cada fase do projeto, h um marco. Eles so
os seguintes:
Fase Marco
Iniciao Escopo ou objetivos do projeto.
Elaborao Arquitetura estabilizada.
Construo Capacidade operacional inicial.
Transio Lanamento do produto.
O marco da iniciao o escopo do projeto, definindo objetivos e necessidades e delimitando sua

rea de aplicao. Observem que j na iniciao, faz-se uma arquitetura inicial do projeto apenas
um esboo. Alm disso, busca-se por riscos de projeto e decide-se sobre a viabilidade do projeto
e sua continuidade.
O marco da elaborao uma arquitetura estabilizada. O que uma arquitetura? Arquitetura

uma macro-organizao do software. um conjunto de casos de uso crticos que foram
implementados similar a um esqueleto que sustenta um corpo. Um problema na arquitetura pode
comprometer todo o projeto.
Uma boa analogia o plano de urbanizao de Braslia feito em 1960. A cidade no estava
completamente povoada, mas ela poderia prever como seria o processo de urbanizao no
decorrer dos anos. No se sabia detalhes, mas se sabia os limites mnimos e mximos que a
arquitetura poderia suportar.
Quando se chega a fase de construo, devemos ter desenvolvimento de software a baixo custo e
alta qualidade. Para tanto, faz-se necessrio criar um certo paralelismo entre as equipes. O marco
da construo uma capacidade operacional inicial do nosso software com parte de suas
funcionalidades prontas.
como uma verso beta do software. A partir da construo, as iteraes comeam a gerar builds,
que so conjunto de casos de uso implementados. O marco da transio o lanamento do
produto, de fato. Observao importante: na implantao que se faz a elaborao de manuais
01176992910
do sistema.
O RUP recomenda alguns nmeros: cada iterao dura de 2 a 6 semanas. O nmero mdio de
iteraes entre 3 e 9 em um projeto de mdia complexidade. Ademais, a disciplina modelagem
de negcios no obrigatria. Alm disso, quando se utiliza o RUP for Small Projects, no h
Modelagem de Negcios nem Implantao.
O RUP apresenta tambm seis princpios chaves para orientar o desenvolvimento de software. So
estratgias altamente recomendadas! Para decorar esses seis princpios, eu lembrava do
mnemnico ABCDEF (i.e., essas so as letras iniciais de cada um dos princpios basta ficar ligado
nisso!). Percebam:

Adaptar processos: o processo unificado serve tanto para desenvolver um sistema de
automao da Coca-Cola quanto para desenvolver o software de uma Padaria. Portanto, pode-
se dizer que o RUP um framework com bastantes ferramentas que se adaptam aos processos
em que ser utilizado.
Balancear prioridades dos interessados: em uma organizao, pode haver vrias pessoas com
opinies distintas a respeito das necessidades da organizao. O RUP afirma que se deve
chegar a um consenso ou algo prximo, evitando personalizaes e customizaes e
apostando em uma padronizao geral.
Colaborao entre times: deve-se dividir as equipes de acordo com as habilidades, de modo
que aumente a produtividade e que haja maior interao entre as equipes por meio de trocas
de experincias e orientaes. A harmonia entre as pessoas essencial para o bom
desenvolvimento do projeto.
Demonstrar o valor da iteratividade: a iteratividade (interatividade, no!) proporciona a

possibilidade de se adaptar a mudanas no escopo, tempo ou custo. Ao tratar os riscos mais
prioritrios no incio do projeto, desenvolve-se uma arquitetura mais robusta, sendo possvel
prever o andamento do projeto.
Elevar o nvel de abstrao: o perfil dos atores determina o nvel de abstrao que deve ser
utilizado. Adequar o nvel de abstrao aumenta a produtividade. Deve-se falar com o usurio
final em um abstrao maior para que ele entenda e com um programador em um abstrao
menor, porque ele entende.
Foco contnuo na qualidade: o processo unificado no possui uma disciplina exclusiva para
qualidade, justamente por ela estar contida em todas as disciplinas e em todas as fases. O RUP
afirma que se deve escolher processos de qualidade e que esse deve ser um foco constante
durante o desenvolvimento.
Por fim, gostaria de apresentar alguns conceitos importantes: papis, produto de trabalho e tarefas.
Papel (Role): uma definio abstrata de um conjunto de atividades executadas e dos

respectivos artefatos. Ele define o comportamento e as responsabilidades de um indivduo ou
01176992910
de um conjunto de indivduos que trabalham juntos como uma equipe, no contexto de uma
organizao.
Tarefas (Tasks): uma unidade de trabalho que um indivduo, desempenhando o papel

descrito, pode ser chamado a realizar. A tarefa tem uma finalidade clara, normalmente expressa
em termos da criao ou atualizao de alguns artefatos como um modelo, uma classe, um
plano. Toda tarefa atribuda a um papel especfico.
Produto de Trabalho (Work Product): uma abstrao geral que representa algum resultado
de um processo. Pode ser um Artefato, Resultado ou Entrega.
o Artefato: um produto de trabalho tangvel e bem definido, produzido ou modificado

por tarefas. Artefatos podem ser compostos por outros artefatos.

o Entrega: um produto de trabalho que prov uma descrio e definio para o

empacotamento de outro produto de trabalho.
o Resultado: um produto de trabalho intangvel, como um servidor instalado ou uma

rede otimizada.
IMPORTANTE
Normalmente, os papis so desempenhados por uma pessoa ou um grupo de pessoas que trabalham juntas. Um
membro da equipe geralmente desempenha muitos papis distintos. Lembrem-se: papis no so pessoas, eles
descrevem como pessoas se comportam no negcio e quais so suas responsabilidades.
Figura 14 - Tipos de Produto de Trabalho.
Em suma, um artefato um modelo, uma entrega a formatao de um artefato e o resultado

a consequncia intangvel (Exemplo: aumento do conhecimento sobre assunto). E o que um
processo? Um Processo define quem (Papel) far o qu (Produto de Trabalho), como (Tarefa) e
quando (Fluxo), de modo a alcanar um objetivo. Por fim, apenas descrio dos principais artefatos:
01176992910
Artefatos Descrio
Documento de Viso Explica o que o projeto aos principais stakeholders.
Casos de Negcio Fornece informaes necessrias para determinar se vale a pena ou

no investir no projeto.
Plano de Desenvolvimento de Rene todas as informaes necessrias ao gerenciamento do projeto.
Software
Modelo de Casos de Uso Modelo de funes futuras do sistema e do ambiente que serve como
um contrato entre as partes.
Glossrio Define termos importantes usados pelo projeto.
Prottipos So usados de uma maneira direta para reduzir o risco.

Lista Classificada em ordem decrescente de importncia e associada
contingncia ou diminuio de riscos.
Documento de Arquitetura de Viso geral de arquitetura do sistema, usando vises para descrever
Software diferentes aspectos do sistema.
Modelo de Projeto Modelo de objeto que descreve a realizao dos casos de uso e serve
como abstrao do modelo.
Modelo de Dados Subconjunto do modelo de implementao que descreve a
representao lgica e fsica dos dados.
Conjunto de Testes Testes implementados e executados para validar a estabilidade da
verso de cada release executvel.
Notas de Release Identificam mudanas e erros em uma verso ou em uma unidade de
implantao disponvel para uso.
Artefatos de Instalao Referem-se ao software e s instrues documentadas necessrias
para instalar o produtos.
Materiais de Treinamento Material usado nos programas ou cursos de para ajudar os usurios
finais a operao dos produtos.
01176992910

METODOLOGIAS GEIS
Em meados de 2001, dezessete especialistas proeminentes da rea

de desenvolvimento de software se reuniram em um resort em Utah
para discutir sobre suas pesquisas e mtodos de desenvolvimento
de software.
Entre eles, estava Martin Fowler (foto ao lado). Aps diversos

debates, eles redigiram um documento intitulado Manifesto gil
para Desenvolvimento de Software, que trazia um conjunto de
definies a respeito sobre essa abordagem.
Por que valorizar mais indivduos e suas interaes do que processos e ferramentas? Porque
auto-organizao e motivao importante, assim como programadores trabalhando em
pares em um mesmo local.
Por que valorizar mais software em funcionamento do que documentao abrangente? Porque
apresentar software funcionando aos clientes em uma reunio mais til e desejado do que
apresentar documentos.
01176992910
Figura 15 - Manifesto gil.
Por que valorizar mais colaborao com o cliente do que negociao de contratos? Porque
no possvel coletar todos os requisitos no incio do ciclo de desenvolvimento, portanto
importante envolvimento contnuo do cliente.

Por que valorizar mais a resposta a mudanas do que seguir um planejamento especfico?
Porque necessrio obter respostas rpidas a mudanas e desenvolvimento contnuo do
software.
Por fim, o manifesto enfatiza que os itens direita tm seu valor, entretanto os itens esquerda
so mais valorizad ! A charge abaixo brinca com os mitos sobre desenvolvimento gil. Muitos
acreditam que um desenvolvimento catico, sem ordem, sem planejamento e sem
documentao, mas com foco em rapidez.
Figura 16 - Tirinha sobre Desenvolvimento gil.
Isso um grande equvoco! Primeiro, agilidade diferente de velocidade. A agilidade a

capacidade de responder adequadamente a mudanas (de software, tecnologia, equipes). Quem
realiza um desenvolvimento, de fato, veloz o RAD (j vimos!). Portanto, a agilidade est
relacionada a flexibilidade e capacidade de resposta.
Os Mtodos geis so mais adaptativos e os mtodos convencionais so mais preditivos. Os

Mtodos geis se adaptam s necessidades de um projeto e s suas mudanas. J os Mtodos
Preditivos valorizam mais o planejamento de todos os aspectos do processo de desenvolvimento
de software como um todo.
Entre os princpios do desenvolvimento gil de software, existem: simplicidade; rpida adaptao a

mudanas; quaisquer mudanas no projeto so bem-vindas; softwares ou partes de softwares so
entregues frequentemente; cooperao constante entre a rea de negcio e a rea tcnica;
01176992910
excelncia tcnica, etc.

EXTREME PROGRAMMING (XP)
Em 1996, Kent Beck (foto ao lado) desenvolveu um novo paradigma de

desenvolvimento de software que rompia com grande parte das
metodologias tradicionais e a batizou de Extreme Programming. Por que
extremo? Porque ele recomenda que as boas prticas sejam levadas ao
extremo! Ahn? Como assim?
Testar bom? Ento vamos testar toda hora

Iterar bom? Ento vamos iterar toda hora.
Integrar bom? Ento vamos integrar toda hora.
O XP uma metodologia gil de desenvolvimento de software para equipes pequenas e para

projetos com requisitos vagos e em constante mudana. Ele parte do princpio de que o cdigo-
fonte a melhor documentao, pois qualquer outra se torna rapidamente desatualizada e perde
sua confiabilidade.
No XP, todos os requisitos so expressos como cenrios (tambm chamados histrias do usurio),
que so implementados diretamente como uma srie de tarefas. Os programadores trabalham em
pares e desenvolvem testes para cada tarefa antes da escrita do cdigo. Sempre que h integrao,
h novos testes.
O desenvolvimento incremental apoiado por pequenos e frequentes releases do sistema e por

uma abordagem de descrio de requisitos baseada nos cenrios do cliente. Ademais, o
envolvimento do cliente em tempo integral facilita o desenvolvimento e melhora a qualidade do
produto.
01176992910
Figura 17 - Ciclo de um release.

Prtica Descrio
Planejamento Incremental Os requisitos so registrados em cartes de histrias e as
histrias a serem includas em um release so
determinadas pelo tempo disponvel e sua prioridade
relativa. Os desenvolvedores dividem essas histrias em
tarefas.
Pequenos Releases O conjunto mnimo til de funcionalidade que agrega
valor ao negcio desenvolvido primeiro. Releases do
sistema so frequentes e adicionam funcionalidade
incrementalmente ao primeiro release.
Projeto Simples realizado um projeto suficientemente simples de modo

que atenda aos requisitos atuais e nada mais.
Desenvolvimento Test-First Um framework automatizado de teste unitrio usado

para escrever os testes para uma nova parte da
funcionalidade antes que esta seja implementada.
Portanto, primeiro se escreve o teste, depois faz-se a
implementao.
Refactoring Espera-se que todos os desenvolvedores recriem o
cdigo continuamente to logo os aprimoramentos do
cdigo forem encontrados. Isso torna o cdigo simples
de entender e fcil de manter.
Programao em Pares Os desenvolvedores trabalham em pares, um verificando

o trabalho do outro e fornecendo apoio para realizar
sempre um bom trabalho. Eles utilizam o mesmo mouse,
teclado e monitor.
Propriedade Coletiva Os pares de desenvolvedores trabalham em todas as

reas do sistema, de tal maneira que no se formem ilhas
de conhecimento, com todos os desenvolvedores de
posse de todo o cdigo. Qualquer um pode mudar
qualquer coisa.
Integrao Contnua To logo o trabalho em uma tarefa seja concludo, este
integrado ao sistema como um todo. Depois de qualquer
integrao, todos os testes unitrios do sistema devem ser
realizados.
01176992910
Ritmo Sustentvel Grandes quantidades de horas extras no so

consideradas aceitveis, pois, no mdio prazo, h uma
reduo na qualidade do cdigo e na produtividade.
Trabalhar por longos perodos se torna
contraproducente.
Metforas A equipe se comunica sobre o desenvolvimento de
software por meio de metforas, caso consiga encontrar
uma que realmente faa sentido dentro do contexto e
possa facilitar a comunicao.
Cliente on-site Um representante do usurio final do sistema deve estar

disponvel em tempo integral para apoiar a equipe. No
XP, o cliente um membro da equipe de
desenvolvimento e responsvel por trazer os requisitos
do sistema.

Reunies em P Reunies so realizadas em p para no se perder o foco
nos assuntos, produzindo reunies mais rpidas, somente
abordando as tarefas realizadas e tarefas a realizar pela
equipe no futuro.
O XP apresenta cinco valores fundamentais:
Comunicao: para se desenvolver um sistema, exige-se comunicar os requisitos de sistema

para os desenvolvedores. Em metodologias formais de desenvolvimento de software, esta
tarefa realizada por meio de documentao. O extreme programming favorece projetos
simples, metforas comuns, a colaborao dos usurios e programadores, a comunicao
verbal frequente, e feedback.
Simplicidade: XP incentiva que se comece com a soluo mais simples. Funcionalidades

adicionais podem ser acrescentadas posteriormente. Alega-se que desenvolver funes que
no so necessrias hoje pode ser prejudicial, na medida em que futuramente essa funo
pode no ser mais til. Codificao e projeto de necessidades futuras incertas implicam o risco
de gastar recursos em algo no mais necessrios, embora talvez atrasando aspectos cruciais.
Feedback: o feedback ocorre quando os testes unitrios ou testes de integrao retornam o

estado do sistema aps a implementao das mudanas. Ademais, como os clientes participam
do desenvolvimento de testes, eles podem dar um feedback instantneo. Dessa forma, o cliente
pode orientar o desenvolvimento em uma possvel recodificao do sistema. Quando o cliente
traz um novo requisito, recebe um feedback de tempo e oramento.
Coragem: a coragem permite que os desenvolvedores se sintam confortveis com ao refatorar

o seu cdigo, quando necessrio. Eventualmente, h de se ter coragem para jogar fora um
cdigo ou para remover um cdigo obsoleto, no importa quanto esforo e tempo se gastou
para produzi-lo. Alm disso, coragem significa persistncia, pois um programador pode se
encontrar preso em um problema complexo durante um dia inteiro sem conseguir resolver.
Respeito: aqui se inclui o respeito pelos outros, assim como o auto-respeito. Membros devem
respeitar seu prprio trabalho, sempre se esforando para oferecer alta qualidade e buscando
o melhor projeto para a soluo atravs de refatorao. Ningum na equipe deve se sentir
01176992910
desvalorizado ou ignorado. Isso garante um alto nvel de motivao e incentiva a lealdade

dentro da equipe. Este valor muito dependente dos outros valores.
No XP, as novas verses de software podem ser compiladas vrias vezes por dia e os incrementos
so entregues para os clientes aproximadamente a cada duas semanas. Quando um programador
compila o sistema para criar uma nova verso, ele deve executar todos os testes automatizados
existentes bem como os testes para a nova funcionalidade.
A nova compilao do software ser aceita somente se todos os testes foram executados com
sucesso. Um preceito fundamental da engenharia de software tradicional que voc deve projetar
para a mudana. Em outras palavras, voc deve antecipar mudanas futuras para o software e
projet-lo de tal maneira que essas mudanas possam ser implementadas facilmente.

O Extreme Programming, contudo, descarta esse princpio alegando que projetar para a mudana
, geralmente, um esforo completamente intil. As mudanas antecipadas muitas vezes no
ocorrem e as solicitaes de mudana realizadas so completamente diferentes, causando diversos
prejuzos ao sistema.
O problema com a implementao de mudanas no antecipadas que elas tendem a degradar

a estrutura do software, fazendo com que as mudanas tornem-se cada vez mais difceis de
implementar. O extreme programming lida com este problema defendendo que o software deve
passar por refatoramento constantemente.
Isso significa que a equipe de programao procura por possveis melhorias no software,
implementando-as imediatamente. Portanto, o software deve sempre ser fcil de compreender e
alterar quando novas histrias de usurio so implementadas. Essa agilidade muito importante
no desenvolvimento gil de software.
01176992910

SCRUM
Algum de vocs sabe de onde vem esse nome? Ento vou lhes contar! Esse nome vem do rugby e
utilizado como uma metfora para refletir o alto grau de cooperao necessrio para obter
sucesso. Imagino que poucos de vocs entendam as regras desse esporte, portanto vou explicar
de forma bastante objetiva porque essa metfora utilizada.
No rugby, um time pontua quando a bola cruza a linha de gol e toca o cho sendo carregada
ou por meio de um passe. Caso o jogador seja derrubado, ele deve soltar a bola, e a jogada se
reinicia! Deve haver intensa troca de passes entre os jogadores, de modo a deix-los menos
vulnerveis a serem derrubados por outros jogadores.
Figura 18 - Scrum no Rugby.

01176992910
Bem... cada jogada se inicia quando um Scrum realizado, i.e., forma-se uma parede de fora entre
os jogadores, como mostra a Figura 18. Observem que os jogadores se renem de forma bem
prxima, unindo suas foras e habilidades para trabalhar em conjunto a fim de conseguir recuperar
a bola.
Percebam, portanto, que o time inteiro deve trabalhar para que a equipe possa pontuar.
Diferentemente do Futebol Americano, no h um quarterback ou uma estrela do time todos so
importantes! Pois , a histria fica mais interessante: vamos ver uma das recomendaes de ataque
do rugby.
Pensem continuamente em seu alinhamento em relao ao jogador que carrega a bola e aos
jogadores ao seu redor. Trabalhe duro para estar disponvel quando necessrio. Observem como

isso importante em metodologias geis: trabalhar duro para ajudar a equipe a obter xito nunca
existe: Bem, no h nada aqui para eu fazer agora...!
Acho que agora ficou mais fcil entender de onde vem esse nome vamos teoria? Antes de
comear, uma observao: o guia oficial do Scrum um documento to pequeno (18 pginas) que
eu recomendo fortemente que vocs leiam-no por inteiro, pois ser muito til! Bem... agora sim
vamos ao trabalho!
Scrum um framework (i.e., possui uma estrutura processual) leve, simples de entender e
extremamente difcil de dominar, para desenvolver e manter produtos complexos e adaptativos,
enquanto entrega produtiva e criativamente produtos com o mais alto valor possvel. Complicado
ou no?
Galera, percebam que ele no um processo ou uma tcnica para construir produtos, mas sim
um framework em que pode ser empregado vrios processos e tcnicas. O Framework pode ser
definido como um conjunto de papis, eventos, artefatos e regras associadas a uma equipe no
se esqueam disso.
Ele fundamentado em teorias empricas de controle de processo e emprega uma abordagem

iterativa e incremental (maximizando as oportunidades de feedback) para aperfeioar a previso e
controle de riscos. Ele afirma que o conhecimento vem da experincia e da tomada de decises
baseadas no que conhecido.
Para tal, ele emprega uma abordagem iterativa e incremental para aperfeioar a previsibilidade e
controle de riscos, fundamentando-se em trs pilares fundamentais!
Transparncia: aspectos significativos (e padronizados) devem estar visveis aos

responsveis pelos resultados. Por exemplo: uma linguagem comum a todos os
participantes.
Inspeo: os usurios devem frequentemente inspecionar os artefatos e o progresso, para

detectar indesejveis variaes (no pode ser frequente a ponto de atrapalhar a execuo
das tarefas).
01176992910
Adaptao: o processo ou material sendo produzido deve ser adaptado sempre que um
inspetor verificar desvios que tornem o resultado inaceitvel e, para tanto, ele tem quatros
oportunidades (as reunies).
O Scrum define o conceito de Time Scrum que um time auto-organizvel (escolhe qual a melhor
forma para realizar seu trabalho) e multifuncional (possui todas as competncias e no depende
de outros de fora da equipe). o responsvel por entregar produtos de forma iterativa e
incremental, maximizando as oportunidades de realimentao.
As entregas incrementais de produto pronto garantem que uma verso potencialmente funcional
do produto do trabalho esteja sempre disponvel. Agora o mais importante dessa parte do assunto:

o Time Scrum composto por: um Product Owner, um Scrum Master e uma Equipe de
Desenvolvimento1
Product Owner:
o responsvel por maximizar o valor do produto e do trabalho da equipe de desenvolvimento,
sendo o nico que pode gerenciar o Product Backlog. Ele pode at delegar as atividades de
gerenciamento, mas ainda ser considerado o responsvel pelos resultados. A Equipe de
Desenvolvimento s responde a ele!
Equipe de Desenvolvimento
A Equipe de Desenvolvimento no reconhece ttulos para seus integrantes, todos so considerados
desenvolvedores (no importa o que faam). A Equipe deve ter entre 3 e 9 integrantes, de modo
que no seja pequena demais que haja restries de habilidades nem grande demais que seja
complicado de gerenciar.
Scrum Master
o responsvel por garantir que o Scrum seja entendido e aplicado. Ademais, ele deve comunicar
claramente a viso, objetivo e itens do Product Backlog; ensinar a equipe a criar itens claros e
concisos; treinar a equipe de desenvolvimento em autogerenciamento e interdisciplinaridade;
remover impedimentos; entre outros.
Mudando de assunto, os Eventos Scrum so eventos time-boxed (i.e., com durao mxima) usados
para criar uma rotina e minimizar a necessidade de reunies no definidas pelo Scrum. Lembrem-
se de que a Sprint tem um ms ou menos e iniciada imediatamente aps a concluso da sprint
anterior.
As Sprints so compostas por uma Reunio de Planejamento da Sprint, Reunies Dirias, o Trabalho
de Desenvolvimento, uma Reviso da Sprint e a Retrospectiva da Sprint. Uma Sprint se inicia
imediatamente aps a concluso da sprint anterior e tem duraes coerentes em todo o esforo
de desenvolvimento.
Durante a sprint proibido realizar mudanas que afetem o seu objetivo. Alm disso, proibido
mudar a composio da equipe ou diminuir as metas de qualidade, apesar disso o escopo pode
ser sempre clarificado e renegociado. Essas proibies devem ser levadas muito a srio, vocs
01176992910
entenderam?
Uma sprint pode ser cancelada antes de seu time-box terminar e isso somente pode ser feito pelo
Product Owner (sob influncia de stakeholders, equipe de desenvolvimento, entre outros). Isso
pode ocorrer caso o seu objetivo se torne obsoleto, mas ocorrem tambm devido curta durao
e a cancelamentos, porm so raros os casos.
O trabalho a ser realizado na Sprint planejado na Reunio de Planejamento da Sprint

(Proporcional a 8 horas). Essa reunio consiste em duas partes:
1. O que ser entregue como resultado do incremento da prxima Sprint?
1
No confundir Equipe de Desenvolvimento com Time Scrum o primeiro est contido no segundo.

2. Como o trabalho necessrio para entregar o incremento ser realizado?
Na primeira parte, a Equipe de Desenvolvimento tenta prever as funcionalidades que sero

desenvolvidas durante a Sprint. Na segunda parte, a Equipe de Desenvolvimento decide como ir
construir essas funcionalidades durante a Sprint e desenvolve o Sprint Backlog. Portanto, a primeira
parte trada do O que fazer? e a segunda trata do Como fazer?.
Figura 19 - Processo do SCRUM.
O Product Owner pode estar presente durante a segunda parte da reunio para clarificar
esclarecer itens do Backlog do Produto. A Reunio Diria (proporcional a 15 minutos) um evento
que busca criar um plano para as prximas 24 horas e inspecionar o trabalho desde a ltima
01176992910
Reunio Diria.
Ela ocorre sempre no mesmo horrio e no mesmo local e cada integrante deve responder as
seguintes perguntas:
1. O que foi completado desde a ltima reunio?

2. O que ser feito at a prxima reunio?
3. Quais os obstculos que esto no caminho?
As Reunies Dirias melhoram bastante a comunicao entre os integrantes da equipe, ademais

eliminam a necessidade de outras reunies, identificam e removem impedimentos, destacam e
promovem rpidas tomadas de deciso, e melhoram o nvel de conhecimento da Equipe como um
todo.

A Reviso da Sprint (proporcional a 4 horas) executada no final da Sprint para inspecionar o

incremento e adaptar o Backlog do Produto, se necessrio. Esta uma reunio informal e a
apresentao do incremento destina-se a motivar e obter comentrios e promover a colaborao
entre todos.
Nesta reunio, discute-se: o que foi bem e o que no foi; problemas ocorridos e como foram
resolvidos; Procut Backlog; projees de datas. O resultado o Product Backlog revisado e ajustado.
A Retrospectiva da Sprint (Proporcional a 3 horas) uma chance para o Scrum Team inspecionar a
si prprio e criar um plano de melhorias para a prxima sprint.
Ela inspeciona como foi a ltima sprint em relao s pessoas, s relaes, aos processos e s
ferramentas. Alm disso, tem o poder de identificar e ordenar os principais itens que se tornaram
potenciais de melhorias, e cria um plano para implementar melhorias no modo de realizao do
trabalho.
01176992910
Figura 20 - Grfico Burndown.
O Documento de Viso definido pelo Product Owner e representa como os clientes, usurios
finais, gerentes, stakeholders, executivos, entre outros, visualizam o resultado final do produto que
ser criado. Prticas como Burndown/Burnup tm sido utilizadas para prever o progresso, sem
substituir a importncia do empirismo, como mostra a Figura 20.
O Product Backlog uma lista ordenada (por valor, risco, prioridade etc) de tudo que deve ser
necessrio no produto, e uma origem nica dos requisitos para qualquer mudana a ser feita no
produto. Ele nunca (ateno: nunca, jamais) estar completo e existir enquanto o produto tambm
existir.

MODELAGEM DE PROCESSOS
Primeiro, o que um processo? H dezenas de conceitos diferentes, alguns concernentes a um

domnio especfico. Pode ser definido como o conjunto de atividades inter-relacionadas que
transforma insumos (entradas) em produtos (sadas). Pode ser definido, tambm, como um
conjunto sequencial e particular de aes com objetivo comum.
No contexto de negcio, pode ser definido como um conjunto de atividades ou comportamentos

executados por humanos ou mquinas para alcanar uma ou mais metas. Processos so disparados
por eventos especficos e apresentam resultados que podem conduzir ao trmino do processo ou
a transferncia de controle para outro processo.
Segundo, o que um processo de negcio? uma srie de atividades estruturadas para produzir
um produto ou servio para um cliente ou mercado em particular; so disparados por eventos
especficos, tem incio e fim definidos e solucionam questes especficas. E mais uma coisa: ocorre
dentro de uma empresa!
Compreende um conjunto de atividades realizadas na empresa, associadas s informaes que

manipula, utilizando os recursos dessa empresa. Forma uma unidade coesa e deve ser focalizado
em um tipo de negcio, que normalmente est direcionado a um determinado mercado/cliente,
com fornecedores bem definidos.
Como recursos, pode-se entender tcnicas, mtodos, ferramentas, sistemas de informao,

recursos financeiros e todo o conhecimento envolvido na sua utilizao. A organizao engloba
no somente os aspectos organizacionais e estruturais das empresas, como tambm os seus
agentes, i.e., as pessoas com suas qualificaes, motivaes, etc.
Este foco no negcio importante, pois comum encontrar diversos negcios de uma empresa
compartilhando os mesmos elementos estruturais e recursos, o que dificulta a definio do
Processo de Negcio (e em muitos casos a prpria operao da empresa) essa redundncia no
saudvel para organizao.
01176992910
Se o compartilhamento de recursos for inevitvel, o conhecimento dos Processos de Negcio que

utilizam esses recursos traz este fato conscincia de uma forma sistemtica, auxiliando, ento, no
seu gerenciamento. A existncia de atividades que no agregam valor ao produto tambm dificulta
a identificao dos processos de negcio.
As atividades podem ser classificadas de diversas maneiras:
Atividades Principais: so as que tm participao direta na criao do bem ou servio.

Costumam agrupar-se em logstica, produo, vendas e servios. Essas atividades principais so
divididas em crticas e no-crticas.

Atividades Secundrias: so as que no esto diretamente envolvidas com a produo. Existem
para garantir todas as condies de operacionalidade necessrias s atividades principais com
antecedncia.
Atividades Transversais: so o conjunto de vrias especialidades executadas em uma nica

operao com a finalidade de resolver problemas. Elas possuem carter temporrio ou
provisrio.
Os Processos de Negcio so identificados no mapeamento! Aps serem identificados, eles so

posicionados de forma hierarquizada, representando o nvel de detalhamento com que o trabalho
de modelagem de processos de negcio est sendo tratado. Como assim hierarquizada? Como
mostra a Figura 21!
Esse nvel de detalhamento definido de acordo com as metas e objetivos, numa anlise top-down,
partindo da viso geral da organizao e chegando at as atividades e tarefas que so
desenvolvidas para obter os resultados do processo de negcio analisado. A definio desse nvel
de detalhamento ir delimitar o processo de negcio.
Macroprocessos Processos Subprocessos Funo Atividades Tarefas
Figura 21 - Representao da Hierarquia de Processos.
Macroprocesso: processo que envolve mais de uma rea e gera impacto na organizao.
Processo: conjunto de atividades relacionadas que recebe entradas e produz sadas.
Subprocesso: um processo dentro de outro processo, possibilitando melhor

funcionamento.
Funo: grupo de atividades relacionadas com um objetivo ou tarefa especfica ou

particular. 01176992910
Atividade: so trabalhos executados nos processos ou subprocessos para atingir um

resultado.
Tarefa: o menor elemento de um processo. Um conjunto de tarefas formam uma

atividade.
No mapeamento, no necessrio mapear todos os processos de negcio, mas preciso mapear

aqueles processos crticos ou mais importantes para a organizao. E como se faz isso? Bem, os
processos podem ser de trs tipos: de negcio, organizacionais ou gerenciais. Vamos ver uma
descrio sobre cada um deles.

De Negcio (Finalsticos/Primrios): so aqueles que impactam diretamente o cliente externo.
Se houver falha, o cliente perceber imediatamente.
Os Processos de Negcio, tambm chamados Processos Finalsticos ou Processos Primrios so

ponta-a-ponta, interfuncionais e entregam valor aos clientes. Eles so frequentemente chamados
de processos essenciais, pois representam as atividades de fundamental importncia que uma
organizao desempenha para cumprir sua misso.
Esses processos formam a cadeia de valor onde cada passo agrega valor ao passo anterior
conforme medido por sua contribuio na criao ou entrega de um produto ou servio, em ltima
instncia, gerando valor aos clientes. Prestem bastante ateno nisso, pode-se medir a contribuio
por meio do valor agregado.
Michael Porter descreveu cadeias de valor como compostas de atividades primrias e de suporte.
A cadeia de valor do processo de negcio descreve a forma de contemplar a cadeia de atividades
que fornecem valor ao cliente. Cada uma dessas atividades tem seus objetivos de desempenho
vinculados a seu processo de negcio principal.
Processos Primrios podem mover-se atravs de organizaes funcionais ou departamentos e

prover uma viso completa ponta-a-ponta de criao de valor. Atividades primrias so aquelas
envolvidas com a criao fsica de um produto ou servio, marketing e transferncia ao comprador,
e suporte ps-venda, referidos como agregao de valor.
Organizacionais (de Apoio/Suporte): so aqueles que apoiam os processos finalsticos e

impactam indiretamente o cliente externo.
Esses processos so desenhados para prover suporte a processos primrios, frequentemente pelo
gerenciamento de recursos ou infraestrutura requerida. O principal diferenciador entre processos
primrios e de suporte que processos de suporte no geram valor direto aos clientes e processos
primrios, sim.
Exemplos comuns de processos de suporte incluem gerenciamento de tecnologia da informao,

gerenciamento de infraestrutura ou capacidade e gerenciamento de recursos humanos. Cada um
desses processos de suporte pode envolver um ciclo de vida de recursos e esto frequentemente
01176992910
associados a reas funcionais.
No entanto, os processos de suporte podem e na verdade geralmente atravessam fronteiras

funcionais. Por exemplo, o processo de gerenciar capacidade no entrega valor diretamente ao
cliente, mas suporta a habilidade da organizao em entregar produtos e servios aos seus
usurios.
Gerenciamento de capacidade normalmente envolve certo nmero de atividades interfuncionais,

de planejamento a compra, de engenharia a desenho, construo e o processo de colocar a
capacidade em produo. Cada uma dessas atividades poderia incluir equipes interfuncionais com
representantes de finanas, compras, engenharia, etc.

O fato de processos de suporte no gerarem diretamente valor aos clientes no significa que no
sejam importantes para a organizao. Os processos de suporte podem ser fundamentais e
estratgicos organizao na medida em que aumentam sua capacidade de efetivamente realizar
os processos primrios
Gerenciais (de Gesto): so aqueles que coordenam e planejam as atividades de apoio e os

processos finalsticos.
Processos de Gerenciamento so utilizados para medir, monitorar e controlar atividades de

negcios. Tais processos asseguram que um processo primrio ou de suporte, atinja metas
operacionais, financeiras, regulatrias e legais. No agregam diretamente valor aos clientes, mas
so necessrios a fim de assegurar que a organizao opere eficientemente.
Qualquer processo, do mais simples ao mais complexo, tem que agregar valor, isto , sua sada
para o cliente tem que ser mais valorizada e gerar melhores atributos do que as suas entradas.
Qualquer processo que no agregue valor deve ser considerado como desnecessrio na
organizao e prontamente eliminado.
Ok, mas e o que a Modelagem de Processos de Negcio? Ela consiste na elaborao de um

diagrama e uma documentao do processo de negcio. o conjunto de tecnologias dinmicas
que aborda todo trabalho de uma organizao em tempo real (ponta a ponta). O diagrama
resultante mostra como as atividades fluem de sua entrada para sua sada.
Ele mostra, tambm, como a interao entre os processos e como eles contribuem para a
agregao de valor. J a documentao dos processos de negcio descrevem as propriedades e
as caractersticas desse. O diagrama junto com a documentao formam o conjunto de
documentos resultantes da modelagem de processos de negcio.
Um dos seus principais benefcios a facilitao do entendimento do processo por todas as pessoas
envolvidas com o negcio. Em outras palavras, a modelagem de processos uma forma de
comunicao que facilita a visualizao dos processos de negcio e facilita a entender o que deve
ser feito e por quem deve ser feito.
Aps os questionrios, entrevistas, reunies, workshops, coleta de dados e evidncias, anlise de

01176992910
documentao e polticas da organizao, observaes in loco e anlise dos indicadores e metas

da organizao, fundamental utilizar a tcnica de identificao e mapeamento de processos de
negcio denominada Modelo AS-IS.
E o que o Modelo AS-IS? um modelo de processos de negcio que mostra como os processos
so, de fato, executados pela organizao no momento do mapeamento. Em outras palavras, o
funcionamento atual da organizao. Ele identifica os papis de cada um, a sequncia dos
processos, as regras e indicadores.
Durante o mapeamento, identificam-se problemas na execuo de processos, tarefas duplicadas

ou redundantes, inconsistncias tcnicas e a ordenao dos processos. Aps o mapeamento, pode-
se melhorar os processos e criar o Modelo TO-BE, que representa inovaes que indicam como o
processo deveria ser realizado.

O BPM possui um ciclo composto por seis fases:
Planejamento e Estratgia: identifica-se as necessidades de alinhamento estratgico dos

processos, papis e responsabilidades organizacionais associados ao gerenciamento de
processos, aspectos relacionados a patrocnio, metas, expectativas de desempenho e
metodologias.
Anlise: busca entender os atuais processos organizacionais no contexto dos objetivos

desejados. Congrega informaes oriundas de planos estratgicos, modelos de processo,
desempenho, etc. Analisam-se os objetivos da modelagem, ambiente do negcio,
principais stakeholders e escopo da modelagem.
Modelagem e Desenho: representa graficamente os processos como eles se apresentam

atualmente, buscando-se ao mximo no recorrer reduo ou simplificao de qualquer
tipo. J o desenho consiste na criao de especificaes para processos de negcios novos
ou modificados.
Implementao: realiza o desenho aprovado do processo de negcio anterior na forma de

procedimentos e fluxos de trabalho documentados e exaustivamente testados, podendo
prever tambm a elaborao e execuo de polticas e procedimentos novos ou revisados
da organizao.
01176992910
Figura 22 Melhoria de Processos de Negcio.

Monitoramento e Controle: responsvel pela aferio e validao do processo, como
forma de garantir que o mesmo est representado conforme sua realidade, bem como
pelo estudo de cenrios, possibilitando a anlise de mudanas no processo. Isso
fundamental para reduzir os riscos de implementao do processo.
Refinamento: responsvel pela transformao dos processos, implementando o resultado

da anlise de desempenho. Ele trata de desafios associados gesto de mudanas na
organizao, melhoria contnua (que ns veremos logo a seguir) e otimizao de
processos organizacionais.
A Modelagem de Processos de Negcio possui seis princpios que regulam sua especificao:
aderncia, relevncia ou suficincia, custo-benefcio, clareza, comparabilidade e estrutura sistmica.
Todos so importantes para uma boa modelagem dos processos de negcio e para que uma
organizao alcance seus objetivos e metas.
Existem seis passos para a Melhoria de Processos de Negcio:
Iniciao e Planejamento: define-se, em uma reunio executiva, o escopo do problema, os

principais stakeholders, objetivos primrios, equipe de trabalho, etc.
Mapeamento de Processos: Reunies, Workshops, Entrevistas, questionrios, para

identificar processos. Define notao e ferramentas de modelagem.
Modelagem de Processos: desenha Diagramas AS-IS, validam os modelos construdos e

apresentam o modelos projetado.
Redesenho de Processo: desenha Diagramas TO-BE, analisa os modelos de processos,

valida, apresenta e aprova os modelos.
Implementao: planeja a implementao, implementa o Modelo TO-BE, valida a

implementao e realiza treinamentos.
Encerramento: define o ciclo de melhoria contnua e realiza a reunio executiva de

encerramento do projeto. 01176992910

(CESPE INMETRO Analista de Sistemas) Em uma empresa que tenha adotado um processo
de desenvolvimento de software em cascata, falhas no levantamento de requisitos tm maior
possibilidade de gerar grandes prejuzos do que naquelas que tenham adotado desenvolvimento
evolucionrio.
Comentrios:
Modelo em Cascata, de fato, no reage bem a mudanas. J Modelo evolucionrio mais adaptvel a
mudanas por se utilizar de iteraes.
Gabarito: C
(CESPE 2011 MEC Analista de Sistemas) O modelo Waterfall tem a vantagem de facilitar a realizao
de mudanas sem a necessidade de retrabalho em fases j completadas.
Comentrios:
Pelo contrrio, h dificuldade de lidar com requisitos volteis, tendo em vista que dependendo do erro,
necessrio refaz-lo desde seu incio.
Gabarito: E
(CESPE TST Analista de Sistemas) No modelo de desenvolvimento sequencial linear, a fase de

codificao a que gera erros de maior custo de correo.
Comentrios:
Na verdade, a fase levantamento de requisitos que gera erros de maior custo de correo. Ser
desenvolvido algo que no tem utilidade para o cliente e ter que ser modificado.
Gabarito: E
01176992910
(CESPE INMETRO Analista de Sistemas) Em um processo de desenvolvimento em cascata, os

testes de software so realizados todos em um mesmo estgio, que acontece aps a finalizao das fases
de implementao.
Comentrios:
Na verdade, na implementao so feitos testes unitrios, aps a implementao so feitos testes de

integrao, aps a implantao so feitos testes de carga, e vrios outros.
Gabarito: E
(CESPE SERPRO Analista de Sistemas) O modelo em cascata consiste de fases e atividades

que devem ser realizadas em sequncia, de forma que uma atividade requisito da outra.

Comentrios:
Vimos isso exaustivamente: uma fase s se inicia aps o trmino e aprovao da fase anterior.
Gabarito: C
(CESPE SERPRO Analista de Sistemas) Para a especificao de software e verificao de

sistemas, uma alternativa que se fundamenta na matemtica discreta e na lgica o modelo incremental.
Comentrios:
Na verdade, so os Mtodos Formais!
Gabarito: E
(CESPE 2010 TRE/BA Tcnico Judicirio Programao de Sistemas) Na engenharia de software

baseada em componentes, na qual se supe que partes do sistema j existam, o processo de
desenvolvimento concentra-se mais na integrao dessas partes que no seu desenvolvimento a partir do
incio. Essa abordagem baseada em reso para o desenvolvimento de sistemas de software.
Comentrios:
Questo perfeita!
Gabarito: C
(CESPE MPE/AM Analista Judicirio Analista de Sistemas) A utilizao de um modelo de

desenvolvimento embasado em componentes uma forma de desenvolvimento em espiral que busca a
reutilizao de trechos de software desenvolvidos e testados em projetos anteriores e armazenados em
um repositrio.
Comentrios:
De fato, o modelo de desenvolvimento baseado em componentes incorpora caractersticas do modelo em

espiral, preconizando o uso de componentes comerciais prontos para uso.
01176992910
Gabarito: C
(FGV Senado Federal Analista de Sistemas) No modelo evolucionrio, a mudana constante

tende a corromper a estrutura do software.
Comentrios:
Como j discutimos, isso realmente acontece!
Gabarito: C
10. (CESPE 2013 TRT/10 Analista Judicirio Tecnologia da Informao) No modelo prototipao, a
construo de software tem vrias atividades que so executadas de forma sistemtica e sequencial.
Comentrios:

Na verdade, quem constri software por meio de atividades executadas de forma sistemtica e sequencial
o modelo em cascata.
Gabarito: E
(CESPE TCE/RN Assessor Tcnico de Informtic A prototipao, uma abordagem para

desenvolvimento de software na qual se cria um modelo do software que ser implementado,
composta de quatro etapas: planejamento, anlise de risco, engenharia e avaliao do cliente.
Comentrios:
Opa... essas etapas so da Modelagem em Espiral.
Gabarito: E
12. (CESPE 2011 MEC Anlise de Sistemas) No modelo de prototipao, o processo de desenvolvimento
de software modelado como uma sequncia linear de fases, enfatizando um ciclo de desenvolvimento
de breve durao.
Comentrios:
Na verdade, no linear - iterativo.
Gabarito: E
13. (CESPE 2011 MEC Gerente de Projetos) O modelo de processo denominado em espiral combina as
atividades de desenvolvimento com o gerenciamento de riscos, de modo a minimiz-los e control-los.
Comentrios:
Perfeito. Vimos isso exaustivamente!
Gabarito: C
14. (CESPE TJ/DF Analista Judicirio Tecnologia da Informao) O modelo em espiral um

modelo de processos de software que rene a natureza iterativa da prototipao com os aspectos
01176992910
sistemticos e controlados do modelo sequencial linear.
Comentrios:
Modelo em espiral tambm conhecido como prototipagem-em-etapas, por conta disso.
Gabarito: C
15. (CESPE ANTAQ Analista Administrativo Informtica) O modelo em espiral, que descreve o
processo de desenvolvimento de um software, apresenta uma espiral em que cada loop representa uma
fase distinta desse processo. A ausncia de risco nesse modelo o diferencia dos demais modelos de
software.
Comentrios:

Na verdade, a presena da anlise de riscos que o diferencia.
Gabarito: E
16. (CESPE TJ/DF Analista Judicirio Tecnologia da Informao) Empregando o modelo de

desenvolvimento em espiral, o software desenvolvido em uma srie de verses intermedirias
incrementais.
Comentrios:
Exatamente o que diz Pressman.
Gabarito: C
17. (CESPE 2010 SERPRO Desenvolvimento de Sistemas) O modelo em espiral de ciclo de vida de
software iterativo e incremental, uma vez que a mesma sequncia de atividades relacionadas
produo de software realizada a cada ciclo da espiral.
Comentrios:
Na verdade, ele evolucionrio e nem sempre a mesma sequncia de atividades realizada.
Gabarito: E
18. (CESPE 2010 SERPRO Desenvolvimento de Sistemas) O modelo de desenvolvimento em espiral

permite repensar o planejamento diversas vezes durante o desenrolar do projeto.
Comentrios:
Ele iterativo, portanto permite replanejamento a cada nova iterao.
Gabarito: C
19. (CESPE 2011 TJ/ES Analista Judicirio alista de Sistemas) O modelo de processo incremental de
desenvolvimento de software iterativo, assim como o processo de prototipagem. Contudo, no processo
incremental, diferentemente do que ocorre no de prototipagem, o objetivo consiste em apresentar um
01176992910
produto operacional a cada incremento.
Comentrios:
De fato, no modelo iterativo e incremental, apresenta-se sempre um produto a cada incremento. J na

prototipao, no. Idealmente, ele serve apenas para identificar requisitos.
Gabarito: C
20. (CESPE TJ/DF Analista Judicirio Tecnologia da Informao) No modelo de desenvolvimento

incremental, embora haja defasagem entre os perodos de desenvolvimento de cada incremento, os
incrementos so desenvolvidos em paralelo.
Comentrios:

Questo perfeita. Os incrementos so codificados no exatamente em paralelo h uma pequena

defasagem.
Gabarito: C
21. (CESPE TST Analista Judicirio Analista de Sistemas) O modelo RAD (Rapid Application
Development) consiste em uma forma de prototipao para esclarecer dvidas da especificao do
software.
Comentrios:
RAD um processo de desenvolvimento de software iterativo e incremental que enfatiza um ciclo de

desenvolvimento curto. Ele no uma forma de prototipao, apesar de poder utiliz-la.
barito: E
22. (CESPE ANS Analista Administrativo Processamento de Dados) O modelo Rapid Application
Development (RAD) uma adaptao do modelo em espiral para atender a projetos de software
fundamentados em componentes.
Comentrios:
Na verdade, ele uma adaptao de alta velocidade do modelo em cascata.
Gabarito: E
23. (CESPE MPE/AM Analista Judicirio Analista de Sistemas) O modelo RAD (Rapid Application
Development) especfico para projetos de software que empregam linguagens de programao de
terceira gerao.
Comentrios:
No existe qualquer limitao quanto a isso.
Gabarito: E
01176992910
24. (CESPE 2013 INPI Analista de Planejamento Desenvolvimento e Manuteno de Sistemas) De

acordo com a perspectiva de gerenciamento, o ciclo de vida de software do iRUP (IBM Rational Unified
Process) divide-se em nove disciplinas sequenciais, sendo cada disciplina concluda por um artefato
principal e consistida em um intervalo de tempo entre dois marcos principais, de modo que, ao final de
cada ciclo, tem-se uma verso do produto.
Comentrios:
Na verdade, o ciclo de vida de software que dividido em quatro fases sequenciais. As disciplinas no
ocorrem, necessariamente, em sequncia.
Gabarito: E

25. (CESPE 2013 INPI Analista de Planejamento Desenvolvimento e Manuteno de Sistemas) No
iRUP, o marco das fases de iniciao, elaborao, construo e transio so, respectivamente, objetivo
do ciclo de vida, arquitetura do ciclo de vida, capacidade operacional inicial e release do produto.
mentrios:
Perfeito, bastava saber os marcos.
Gabarito: C
26. (CESPE 2013 ANP Analista Administrativo rea 5) Na fase de iniciao do RUP (Rational Unified
Process), o projeto do sistema elaborado com foco na arquitetura do sistema a ser implantado.
Comentrios:
Na verdade, a fase de iniciao tem foco na definio do escopo e objetivos do projeto, apesar de j se
construir um esboo de arquitetura do sistema.
Gabarito: E
27. (CESPE 1 MEC Gerente de Projetos) No RUP (Rational Unified Process), a qualidade de software
um quesito contemplado somente nas seguintes fases do ciclo de desenvolvimento: implementao,
teste e entrega.
Comentrios:
Um dos princpios bsicos do processo unificado o Foco Contnuo na Qualidade e uma das prticas
recomendadas a Contnua Verificao da Qualidade. Portanto, a qualidade contemplada em todas as
fases do ciclo de desenvolvimento.
Gabarito: E
28. (CESPE 2011 EBC Analista de Sistemas) O RUP tem duas dimenses: o eixo horizontal e o eixo
vertical. A primeira dimenso representa o aspecto esttico do processo quando ele aprovado e
expressa em termos de fases, iteraes e marcos. A segunda dimenso representa o aspecto dinmico
do processo, como ele descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho,
artefatos e papis do processo. 01176992910
Comentrios:
A questo inverteu os conceitos: eixo horizontal representa aspectos dinmicos e eixo vertical representa
aspectos estticos.
Gabarito: E
29. (CESPE 2012 TCE/ES Auditor de Controle Externo Tecnologia da Informao) Em virtude de as
metodologias geis gerarem excessiva documentao, a gesto do conhecimento depende diretamente
dos programadores envolvidos no projeto.
Comentrios:

O manifesto gil preconiza: software em funcionamento mais do que documentao abrangente. Portanto,
metodologias geis consideram que a melhor documentao o prprio cdigo.
Gabarito: E
30. (CESPE 2011 EBC Analista de Sistemas) O que os mtodos geis buscam como evitar as mudanas
desde o incio do projeto e no a melhor maneira de tratar essas mudanas.
Comentrios:
Na verdade, mtodos geis so extremamente adequados mudana de requisitos, adaptando-se a novos

contextos e respondendo a cada modificao.
Gabarito: E
31. (CESPE 2010 BASA Tcnico Cientfico Arquitetura de Tecnologia) Desenvolvimento gil de software
(Agile Software Development) ou mtodo gil aplicado, principalmente, a grandes corporaes, uma
vez que permite produzir grandes sistemas de forma gil.
Comentrios:
Pelo contrrio, mais adequado para pequenas e mdias empresas (Sommerville).
Gabarito: E
32. (CESPE 2010 TCU Auditor Federal de Controle Externo Tecnologia da Informao) A agilidade
no pode ser aplicada a todo e qualquer processo de software.
Comentrios:
Claro que pode ser aplicado a todo e qualquer tipo de processo de software, mas indiscriminadamente? No.
H certas circunstncias.
Gabarito: C
33. (CESPE SECONT/ES Auditor do Estado Tecnologia da Informao) Mtodos geis de

desenvolvimento de sistemas foram propostos principalmente para apoiar o desenvolvimento de
01176992910
aplicaes de negcios nas quais os requisitos de sistema mudam rapidamente durante o processo de
desenvolvimento. Entre esses mtodos est o extreme programming, que envolve um nmero de
prticas, como o planejamento incremental, a definio de um ritmo de trabalho sustentvel e a diviso
das equipes de trabalho por meio da especializao de seus membros.
Comentrios:
Esta questo est quase toda correta, exceto pela ltima parte. XP recomenda que no haja especializao
de membros, apresentando uma equipe coesa e multidisciplinar.
Gabarito: E
34. (CESPE 2012 MPE/PI Analista Ministerial Cargo 6) O XP (Extreme Programming) um mtodo
gil, que preconiza a criao de um caso de teste unitrio antes do incio da codificao.

Comentrios:
O XP, de fato, um mtodo gil que preconiza o test-first design como uma de suas prticas, isto , primeiro
cria-se o teste para depois codificar a funcionalidade.
Gabarito: C
35. (CESPE 2011 EBC Analista de Sistemas Engenharia de Software) O XP segue um conjunto de
valores, princpios e regras bsicas que visam alcanar eficincia e efetividade no processo de
desenvolvimento de software. Os valores so cinco: comunicao, simplicidade, feedback, coragem e
respeito.
Comentrios:
De fato, so realmente esses os valores do XP!
Gabarito: C
36. (CESPE 2010 TRE/BA Tcnico Judicirio Programao de Sistemas) Em XP, a prtica denominada
programao em pares (pair programming) realizada por um desenvolvedor em dois computadores,
com o objetivo de aumentar a produtividade.
Comentrios:
Na verdade, so dois desenvolvedores utilizando apenas um computador. Ademais, o intuito aumentar a

qualidade do software que ser sempre revisado pelo par.
Gabarito: E
37. (CESPE 2011 STM Analista Judicirio Analista de Sistemas) O Extreme Programming (XP), que se
inclui entre os mtodos geis, apresenta, entre outras, as seguintes caractersticas: pequenos releases,
projeto simples, refactoring, programao em pares e propriedade coletiva.
Comentrios:
Perfeito, todas essas so caractersticas do Extreme Programming.

01176992910
Gabarito: C
38. (CESPE 2010 ABIN Oficial Tcnico de Inteligncia Desenvolvimento e Manuteno de Sistemas)
Na Extreme Programming, os requisitos so expressos como cenrios e implementados diretamente
como uma srie de tarefas. O representante do cliente faz parte do desenvolvimento e responsvel
pela definio de testes de aceitao do sistema.
Comentrios:
Perfeito, os requisitos so expressos como cenrios (ou estrias de usurio) e implementados como tarefas.
Ademais, recomenda-se o Cliente on-site, isto , um representante do usurio final do sistema deve estar
disponvel em tempo integral para apoiar a equipe.

Gabarito: C
39. (CESPE 2013 ANP Analista Administrativo rea 5) De acordo com a metodologia Scrum, a
constituio ideal da equipe de desenvolvimento para que o trabalho se mantenha gil deve ser de
menos de trs pessoas.
Comentrios:
Na verdade, recomenda-se entre trs e nove participantes. Com menos de trs participantes, reduz-se a
interao que gera um menor ganho de produtividade.
Gabarito: E
40. (CESPE 2013 ANAC Analista Administrativo rea 4) O nico papel definido pelo Scrum com
autoridade para cancelar uma Sprint o do Product Owner.
Comentrios:
De fato, apenas o Product Owner pode cancelar uma sprint.
Gabarito: C
41. (CESPE 2013 ANAC Analista Administrativo rea 4) Uma sprint do Scrum tem durao prevista de
2 meses.
Comentrios:
Uma sprint deve ter entre duas e quarto semanas.
Gabarito: E
42. (CESPE - 2012 - TRE-RJ - Tcnico Judicirio - Programao de Sistemas) A metodologia scrum prega que
a equipe complete e entregue partes do produto final constantemente ao final de cada interao. Essa
interao deve ser curta e possuir tempo de execuo definido previamente.
Comentrios:
01176992910
De fato, h entregas frequentes de partes do produto e h iteraes curtas com tempo de execuo definido.
Opa, percebam que eu disse que h iteraes curtas e, no, interaes curtas como disse a questo. Essa
questo deveria ter sido anulada, mas no foi!
Gabarito: C
43. (CESPE - 2010 - BASA - Tcnico Judicirio Arquitetura de Tecnologia) O Scrum utilizado, como funo
primria, para o gerenciamento de projetos de desenvolvimento de software, mas tambm tem sido
usado como Extreme Programming e outras metodologias de desenvolvimento. Teoricamente, o Scrum
pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessite trabalhar juntas para
atingir um objetivo comum.
Comentrios:

Questo perfeita. Scrum est para o PMBOK, assim como o XP est para o RUP. Ele pode ser utilizado, em
teoria, em qualquer contexto em que se necessite atingir um objetivo comum entre um grupo de pessoas.
Gabarito: C
44. (CESPE - 2011 - EBC - Analista - Engenharia de Software) No contexto do BPM, um processo um
conjunto definido de atividades ou comportamentos executados por humanos ou mquinas para
alcanar uma ou mais metas. Os processos possuem atributos e caractersticas que descrevem
propriedades, comportamento, propsito, ou outros elementos de processo.
Comentrios:
Essa a definio encontrada no BPM CBOK (Business Process Management Common Body of Knowledge).
Gabarito: C
45. (CESPE - 2011 - -ES - Tcnico de Informtica Especficos) Uma atividade composta por um conjunto
de processos necessrios para se atingir um objetivo organizacional bem definido, com entradas e sadas
especficas para cada processo.
Comentrios:
Opa, qual ?! H uma inverso de palavras. Na verdade, um processo composto por um conjunto de
atividades necessrias para se atingir um objetivo organizacional bem definido, com entradas e sadas
Gabarito: E
46. (CESPE - 2010 - TRE-BA - Analista Judicirio - Anlise de Sistemas) Atividades so conjuntos de tarefas,
com incio e fim identificveis, reunidas segundo critrios de similaridade e de complementaridade,
executadas continuamente, de forma cclica, simultnea ou sequencial para a consecuo dos objetivos
da funo a que pertencem.
Comentrios:
Pessoal, h tantas definies de atividade esse apenas mais um deles.

01176992910
Gabarito: C
47. (CESPE - 2010 - TRE-BA - Analista Judicirio - Anlise de Sistemas) Macroprocessos so conjuntos de
atividades executadas de forma sequencial e contnua, necessrias e suficientes para a obteno de
solues integradas de produtos e servios capazes de satisfazer s necessidades dos clientes. Os
macroprocessos so autnomos, respondem por um resultado especfico e tm, perfeitamente definidos
e sob sua gesto, no somente os objetivos a serem atendidos, mas tambm os meios necessrios para
a obteno dos resultados pactuados.
Comentrios:
Questo perfeita!
Gabarito: C

48. (CESPE - - ANTAQ - Analista Administrativo - Informtica) A modelagem de processos resulta em

representao comportamental, que pode ser realizada com relao tanto aos fluxos, conjuntos de
processos, quanto aos detalhes do processo, ou seja, nas atividades a ele inerentes.
Comentrios:
De fato, representa-se o comportamento dos processos por meio de suas atividades.
Gabarito: C
01176992910

LISTA DE EXERCCIOS COMENTADOS
(CESPE INMETRO Analista de Sistemas) Em uma empresa que tenha adotado um processo
de desenvolvimento de software em cascata, falhas no levantamento de requisitos tm maior
possibilidade de gerar grandes prejuzos do que naquelas que tenham adotado desenvolvimento
evolucionrio.
(CESPE 2011 MEC Analista de Sistemas) O modelo Waterfall tem a vantagem de facilitar a realizao
de mudanas sem a necessidade de retrabalho em fases j completadas.
(CESPE TST Analista de Sistemas) No modelo de desenvolvimento sequencial linear, a fase de

codificao a que gera erros de maior custo de correo.
(CESPE INMETRO Analista de Sistemas) Em um processo de desenvolvimento em cascata, os

testes de software so realizados todos em um mesmo estgio, que acontece aps a finalizao das fases
de implementao.
(CESPE SERPRO Analista de Sistemas) O modelo em cascata consiste de fases e atividades

que devem ser realizadas em sequncia, de forma que uma atividade requisito da outra.
(CESPE SERPRO Analista de Sistemas) Para a especificao de software e verificao de

sistemas, uma alternativa que se fundamenta na matemtica discreta e na lgica o modelo incremental.
(CESPE 2010 TRE/BA Tcnico Judicirio Programao de Sistemas) Na engenharia de software

baseada em componentes, na qual se supe que partes do sistema j existam, o processo de
desenvolvimento concentra-se mais na integrao dessas partes que no seu desenvolvimento a partir do
incio. Essa abordagem baseada em reso para o desenvolvimento de sistemas de software.
(CESPE MPE/AM Analista Judicirio Analista de Sistemas) A utilizao de um modelo de

desenvolvimento embasado em componentes uma forma de desenvolvimento em espiral que busca a
reutilizao de trechos de software desenvolvidos e testados em projetos anteriores e armazenados em
um repositrio.
(FGV Senado Federal Analista de Sistemas) No modelo evolucionrio, a mudana constante

01176992910
tende a corromper a estrutura do software.
10. (CESPE 2013 TRT/10 Analista Judicirio Tecnologia da Informao) No modelo prototipao, a
construo de software tem vrias atividades que so executadas de forma sistemtica e sequencial.
(CESPE TCE/RN Assessor Tcnico de Informtic A prototipao, uma abordagem para

desenvolvimento de software na qual se cria um modelo do software que ser implementado,
composta de quatro etapas: planejamento, anlise de risco, engenharia e avaliao do cliente.
12. (CESPE 2011 MEC Anlise de Sistemas) No modelo de prototipao, o processo de desenvolvimento
de software modelado como uma sequncia linear de fases, enfatizando um ciclo de desenvolvimento
de breve durao.
13. (CESPE 2011 MEC Gerente de Projetos) O modelo de processo denominado em espiral combina as
atividades de desenvolvimento com o gerenciamento de riscos, de modo a minimiz-los e control-los.

14. (CESPE TJ/DF Analista Judicirio Tecnologia da Informao) O modelo em espiral um

modelo de processos de software que rene a natureza iterativa da prototipao com os aspectos
sistemticos e controlados do modelo sequencial linear.
15. (CESPE ANTAQ Analista Administrativo Informtica) O modelo em espiral, que descreve o
processo de desenvolvimento de um software, apresenta uma espiral em que cada loop representa uma
fase distinta desse processo. A ausncia de risco nesse modelo o diferencia dos demais modelos de
software.
16. (CESPE TJ/DF Analista Judicirio Tecnologia da Informao) Empregando o modelo de

desenvolvimento em espiral, o software desenvolvido em uma srie de verses intermedirias
incrementais.
17. (CESPE 2010 SERPRO Desenvolvimento de Sistemas) O modelo em espiral de ciclo de vida de
software iterativo e incremental, uma vez que a mesma sequncia de atividades relacionadas
produo de software realizada a cada ciclo da espiral.
18. (CESPE 2010 SERPRO Desenvolvimento de Sistemas) O modelo de desenvolvimento em espiral

permite repensar o planejamento diversas vezes durante o desenrolar do projeto.
19. (CESPE 2011 TJ/ES Analista Judicirio alista de Sistemas) O modelo de processo incremental de
desenvolvimento de software iterativo, assim como o processo de prototipagem. Contudo, no processo
incremental, diferentemente do que ocorre no de prototipagem, o objetivo consiste em apresentar um
produto operacional a cada incremento.
20. (CESPE TJ/DF Analista Judicirio Tecnologia da Informao) No modelo de desenvolvimento

incremental, embora haja defasagem entre os perodos de desenvolvimento de cada incremento, os
incrementos so desenvolvidos em paralelo.
21. (CESPE TST Analista Judicirio Analista de Sistemas) O modelo RAD (Rapid Application
Development) consiste em uma forma de prototipao para esclarecer dvidas da especificao do
software.
22. (CESPE ANS Analista Administrativo Processamento de Dados) O modelo Rapid Application
Development (RAD) uma adaptao do modelo em espiral para atender a projetos de software
fundamentados em componentes.
01176992910
23. (CESPE MPE/AM Analista Judicirio Analista de Sistemas) O modelo RAD (Rapid Application
Development) especfico para projetos de software que empregam linguagens de programao de
terceira gerao.
24. (CESPE 2013 INPI Analista de Planejamento Desenvolvimento e Manuteno de Sistemas) De

acordo com a perspectiva de gerenciamento, o ciclo de vida de software do iRUP (IBM Rational Unified
Process) divide-se em nove disciplinas sequenciais, sendo cada disciplina concluda por um artefato
principal e consistida em um intervalo de tempo entre dois marcos principais, de modo que, ao final de
cada ciclo, tem-se uma verso do produto.
25. (CESPE 2013 INPI Analista de Planejamento Desenvolvimento e Manuteno de Sistemas) No

iRUP, o marco das fases de iniciao, elaborao, construo e transio so, respectivamente, objetivo
do ciclo de vida, arquitetura do ciclo de vida, capacidade operacional inicial e release do produto.

26. (CESPE 2013 ANP Analista Administrativo rea 5) Na fase de iniciao do RUP (Rational Unified
Process), o projeto do sistema elaborado com foco na arquitetura do sistema a ser implantado.
27. (CESPE 1 MEC Gerente de Projetos) No RUP (Rational Unified Process), a qualidade de software
um quesito contemplado somente nas seguintes fases do ciclo de desenvolvimento: implementao,
teste e entrega.
28. (CESPE 2011 EBC Analista de Sistemas) O RUP tem duas dimenses: o eixo horizontal e o eixo
vertical. A primeira dimenso representa o aspecto esttico do processo quando ele aprovado e
expressa em termos de fases, iteraes e marcos. A segunda dimenso representa o aspecto dinmico
do processo, como ele descrito em termos de componentes, disciplinas, atividades, fluxos de trabalho,
artefatos e papis do processo.
29. (CESPE 2012 TCE/ES Auditor de Controle Externo Tecnologia da Informao) Em virtude de as
metodologias geis gerarem excessiva documentao, a gesto do conhecimento depende diretamente
dos programadores envolvidos no projeto.
30. (CESPE 2011 EBC Analista de Sistemas) O que os mtodos geis buscam como evitar as mudanas
desde o incio do projeto e no a melhor maneira de tratar essas mudanas.
31. (CESPE 2010 BASA Tcnico Cientfico Arquitetura de Tecnologia) Desenvolvimento gil de software
(Agile Software Development) ou mtodo gil aplicado, principalmente, a grandes corporaes, uma
vez que permite produzir grandes sistemas de forma gil.
32. (CESPE 2010 TCU Auditor Federal de Controle Externo Tecnologia da Informao) A agilidade
no pode ser aplicada a todo e qualquer processo de software.
33. (CESPE SECONT/ES Auditor do Estado Tecnologia da Informao) Mtodos geis de

desenvolvimento de sistemas foram propostos principalmente para apoiar o desenvolvimento de
aplicaes de negcios nas quais os requisitos de sistema mudam rapidamente durante o processo de
desenvolvimento. Entre esses mtodos est o extreme programming, que envolve um nmero de
prticas, como o planejamento incremental, a definio de um ritmo de trabalho sustentvel e a diviso
das equipes de trabalho por meio da especializao de seus membros.
34. (CESPE 2012 MPE/PI Analista Ministerial Cargo 6) O XP (Extreme Programming) um mtodo
gil, que preconiza a criao de um caso de teste unitrio antes do incio da codificao.
35. (CESPE 2011 EBC Analista de Sistemas Engenharia de Software) O XP segue um conjunto de
01176992910
valores, princpios e regras bsicas que visam alcanar eficincia e efetividade no processo de
desenvolvimento de software. Os valores so cinco: comunicao, simplicidade, feedback, coragem e
respeito.
36. (CESPE 2010 TRE/BA Tcnico Judicirio Programao de Sistemas) Em XP, a prtica denominada
programao em pares (pair programming) realizada por um desenvolvedor em dois computadores,
com o objetivo de aumentar a produtividade.
37. (CESPE 2011 STM Analista Judicirio Analista de Sistemas) O Extreme Programming (XP), que se
inclui entre os mtodos geis, apresenta, entre outras, as seguintes caractersticas: pequenos releases,
projeto simples, refactoring, programao em pares e propriedade coletiva.
38. (CESPE 2010 ABIN Oficial Tcnico de Inteligncia Desenvolvimento e Manuteno de Sistemas)
Na Extreme Programming, os requisitos so expressos como cenrios e implementados diretamente

como uma srie de tarefas. O representante do cliente faz parte do desenvolvimento e responsvel
pela definio de testes de aceitao do sistema.
39. (CESPE 2013 ANP Analista Administrativo rea 5) De acordo com a metodologia Scrum, a
constituio ideal da equipe de desenvolvimento para que o trabalho se mantenha gil deve ser de
menos de trs pessoas.
40. (CESPE 2013 ANAC Analista Administrativo rea 4) O nico papel definido pelo Scrum com
autoridade para cancelar uma Sprint o do Product Owner.
41. (CESPE 2013 ANAC Analista Administrativo rea 4) Uma sprint do Scrum tem durao prevista de
2 meses.
42. (CESPE - 2012 - TRE-RJ - Tcnico Judicirio - Programao de Sistemas) A metodologia scrum prega que
a equipe complete e entregue partes do produto final constantemente ao final de cada interao. Essa
interao deve ser curta e possuir tempo de execuo definido previamente.
43. (CESPE - 2010 - BASA - Tcnico Judicirio Arquitetura de Tecnologia) O Scrum utilizado, como funo
primria, para o gerenciamento de projetos de desenvolvimento de software, mas tambm tem sido
usado como Extreme Programming e outras metodologias de desenvolvimento. Teoricamente, o Scrum
pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessite trabalhar juntas para
atingir um objetivo comum.
44. (CESPE - 2011 - EBC - Analista - Engenharia de Software) No contexto do BPM, um processo um
conjunto definido de atividades ou comportamentos executados por humanos ou mquinas para
alcanar uma ou mais metas. Os processos possuem atributos e caractersticas que descrevem
propriedades, comportamento, propsito, ou outros elementos de processo.
45. (CESPE - 2011 - -ES - Tcnico de Informtica Especficos) Uma atividade composta por um conjunto
de processos necessrios para se atingir um objetivo organizacional bem definido, com entradas e sadas
46. (CESPE - 2010 - TRE-BA - Analista Judicirio - Anlise de Sistemas) Atividades so conjuntos de tarefas,
com incio e fim identificveis, reunidas segundo critrios de similaridade e de complementaridade,
executadas continuamente, de forma cclica, simultnea ou sequencial para a consecuo dos objetivos
da funo a que pertencem.
47. (CESPE - 2010 - TRE-BA - Analista Judicirio - Anlise de Sistemas) Macroprocessos so conjuntos de
01176992910
atividades executadas de forma sequencial e contnua, necessrias e suficientes para a obteno de

solues integradas de produtos e servios capazes de satisfazer s necessidades dos clientes. Os
macroprocessos so autnomos, respondem por um resultado especfico e tm, perfeitamente definidos
e sob sua gesto, no somente os objetivos a serem atendidos, mas tambm os meios necessrios para
a obteno dos resultados pactuados.
48. (CESPE - - ANTAQ - Analista Administrativo - Informtica) A modelagem de processos resulta em

representao comportamental, que pode ser realizada com relao tanto aos fluxos, conjuntos de
processos, quanto aos detalhes do processo, ou seja, nas atividades a ele inerentes.

1 2 3 4 5 6 7 8 9 10
C E E E C E C C C E
11 12 13 14 15 16 17 18 19 20
E E C C E C E C C C
21 22 23 24 25 26 27 28 29 30
E E E E C E E E E E
31 32 33 34 35 36 37 38 39 40
E C E C C E C C E C
41 42 43 44 45 46 47 48 49 50
E C C C E C C C
01176992910

Idioma

Bem-vindo(a) ao Scribd!

Aula01_Item 8, Até Metodologias Ágeis-CEF

Enviado por

Dados do documento

Descrição:

Data de envio

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Descrição:

Direitos autorais:

Formatos disponíveis

Aula01_Item 8, Até Metodologias Ágeis-CEF

Enviado por

Descrição:

Direitos autorais:

Formatos disponíveis

Títulos relacionados

Edited with the trial version of

Foxit Advanced PDF Editor

Professor: Diego Carvalho

Breve apresentao: meu nome Diego Carvalho, bacharel em Cincia da Computao

com esse salrio,

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 1 de 68

INFORMAES SOBRE O CONCURSO

Concurso da Caixa Econmica Federal DF, SP e RJ - 2014

Remunerao: R$2.025,00 30 horas semanais.

Valor da Inscrio: R$43,00.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 2 de 68

INFORMAES SOBRE O CURSO

O curso que eu proponho abranger todo o contedo, entretanto impossvel e invivel

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 3 de 68

Aula Data Tpicos do Edital

/02 - Engenharia de software. Noes sobre: Modelagem de processos, Ciclo de vida do

/02 - Padres de projeto.

2 2 - Anlise por pontos de funo. Conceitos bsicos e aplicaes.

2 - Engenharia de requisitos. Conceitos bsicos. Noes sobre: tcnicas de elicitao de

06/02 - Testes de software: conceitos e aplicaes. Testes unitrios, de integrao e de

3 - Portais corporativos: arquitetura da informao, Portlets e RSS. Ferramentas de Gesto

3 - Gerncia de configurao: conceitos e prticas. Uso de ferramentas de gerncia de

e fim...! Porque a prova dia 23/03!

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 4 de 68

Destaques em vermelho: quase todos os pargrafos possuem alguma palavra ou frase

4 Faam muitos exerccios: ler vrias bibliografias muito trabalhoso e, geralmente, no

7 Diversas figuras: essas aulas estaro em constante evoluo, sempre procura de

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 5 de 68

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 6 de 68

CICLO DE VIDA E METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE

O processo de desenvolvimento de software refere-se a todas as atividades, relacionamentos,

Figura 1 - Principais Modelos de Ciclo de Vida.

Normalmente, ciclos de vida determinam as fases e o relacionamento entre as fases. Os modelos

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 7 de 68

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 8 de 68

O primeiro modelo designado Cascata ou Clssico ou Sequencial ou Linear ou Waterfall ou Rgido

Figura 2 - Modelo em Cascata Genrico.

Por Sommerville Por Yourdon Por Pressman

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 9 de 68

Na prtica, esses estgios se sobrepem e trocam informaes entre si Na teoria, o resultado de

Planejamento: faz-se o esboo do escopo e dos requisitos, alm de estimativas razoveis

Anlise e Especificao de Requisitos: durante essa fase, refina-se os requisitos e o escopo

Implementao: durante essa fase, codifica-se o software como um conjunto de programas

Implantao, Operao e Manuteno: o sistema de software liberado para o cliente,

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 10 de 68

Figura 3 - Progresso do Projeto no Modelo em Cascata.

utilidade para organizao.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 11 de 68

Esse modelo utilizado em ambientes extremamente complexos. So lentos e dispendiosos, alm

Os chamados mtodos formais de desenvolvimento de software no so amplamente usados no

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 12 de 68

A Programao Orientada a Aspectos (POA) uma metodologia de desenvolvimento de software

Interesses Principais (Core Concerns): capturam as funcionalidades centrais de um mdulo.

Ok, mas o que so Aspectos? So propriedades de um sistema envolvendo diversos componentes

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 13 de 68

No, pelo contrrio! Desde o ingresso dos circuitos integrados,

Naquela poca, os custos de hardware estavam caindo, enquanto os custos de software