Buscar

Analise e projeto

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 3, do total de 25 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 6, do total de 25 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 9, do total de 25 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Prévia do material em texto

COLÉGIO ESTADUAL ULYSSES GUIMARÃES 
CURSO TÉCNICO PROFISSIONALIZANTE EM INFORMÁTICA 
 
 
ERINALDO SANCHES NASCIMENTO 
 
 
 
 
 
 
 
 
 
 
METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
FOZ DO IGUAÇU 
2013
 
 
LISTA DE FIGURAS 
 
 
FIGURA 1 – MODELO DE CÓDIGO E CORREÇÃO. ....................................................... 2 
FIGURA 2 – MODELO EM CASCATA. ........................................................................ 4 
FIGURA 3 – MODELO DE CASCATA COM FEEDBACK. ................................................. 5 
FIGURA 4 – MODELO DE DESENVOLVIMENTO PARALELO. .......................................... 6 
FIGURA 5 – METODOLOGIA DE DESENVOLVIMENTO EM FASE. .................................... 8 
FIGURA 6 – METODOLOGIA BASEADA EM PROTOTIPAÇÃO. ......................................... 9 
FIGURA 7 – METODOLOGIA BASEADA EM PROTÓTIPOS DESCARTÁVEIS. .................... 11 
FIGURA 8 – MODELO DE EVOLUÇÃO INCREMENTAL. ................................................ 12 
FIGURA 9 – PROCESSO RUP, BASEADO EM UML. ................................................. 15 
 
 
 
 
SUMÁRIO 
 
 
2 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS ....................... 1 
2.1 CODIFICAR E CORRIGIR ............................................................................ 1 
2.2 PROJETO ESTRUTURADO ......................................................................... 3 
2.2.1 Desenvolvimento em Cascata ................................................................... 3 
2.2.2 Retornar a Cascata ................................................................................... 4 
2.2.3 Desenvolvimento Paralelo ......................................................................... 5 
2.3 DESENVOLVIMENTO RÁPIDO DE APLICATIVOS (RAD) ........................... 6 
2.3.1 Desenvolvimento em Fase ........................................................................ 7 
2.3.2 Prototipação .............................................................................................. 8 
2.3.3 Prototipagem Descartável ....................................................................... 10 
2.3.4 Modelo de Evolução Incremental ............................................................ 11 
2.4 DESENVOLVIMENTO ÁGIL ....................................................................... 11 
2.4.1 Programação Total (XP) .......................................................................... 12 
2.4.2 Scrum ...................................................................................................... 14 
2.5 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE UNIFICADO ...... 15 
2.6 SELEÇÃO DA METODOLOGIA DE DESENVOLVIMENTO APROPRIADA 16 
2.7 EXERCÍCIOS ............................................................................................. 16 
2.8 REFERÊNCIA BIBLIOGRÁFICA ................................................................ 22 
 
 
1 
 
 
2 METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS 
 
 
A metodologia é uma abordagem formalizada para a execução do CVDS. 
Existem várias metodologias de desenvolvimento de sistemas, e cada uma é única, 
com base na solicitação e foca na aplicação de cada fase do CVDS. Algumas 
metodologias são padrões formais utilizados por agências do governo, enquanto 
outras foram desenvolvidas por empresas de consultoria para vender aos clientes. 
Muitas organizações têm metodologias internas que foram aperfeiçoadas ao longo 
dos anos, e eles explicam exatamente como cada fase do CVDS é para ser 
realizado naquela empresa. 
Há muitas maneiras de categorizar metodologias. 
 Se concentrar nos processos de negócio ou os dados que suportam o negócio. 
 Sequenciação das fases do CVDS e da quantidade de tempo e esforço dedicado 
a cada uma. 
 
 
2.1 CODIFICAR E CORRIGIR 
 
 
O primeiro modelo de desenvolvimento de software é o que a maioria de nós 
fazemos quando estamos trabalhando em pequenos projetos desenvolvidos por nós 
mesmos, ou talvez com um único parceiro. É o modelo de código e correção, 
apresentado na Figura 1. 
 Não há requisitos formais. 
 Sem documentação necessária. 
 Nenhuma garantia de qualidade ou testes formais. 
 A liberação é casual na melhor das hipóteses. 
 Sem estimativas de esforço ou cronogramas. 
Codificar e corrigir gasta uma quantidade mínima de tempo para entender o 
problema e, em seguida, inicia a codificação. Compila o código e testá-o. Se não 
funcionar, corrige o problema e tenta novamente. Continua este ciclo de escreve-
compila-executa-corrige até que o programa faça o que você quer sem erros fatais 
e, em seguida, apronte-o para uso. 
2 
 
 
Todo programador conhece esse modelo. Todos nós já usamos mais do que 
uma vez, e ele realmente funciona em determinadas circunstâncias: a rápida, tarefas 
descartáveis. Não há manutenção envolvida e o modelo funciona bem para 
programas pequenos e unipessoais. 
 Sem gerenciamento de configuração, pouco na forma de testes, nenhum 
planejamento arquitetônico e, provavelmente, pouco mais de um controle 
documental do programa para uma revisão de código, esse modelo é bom para 
protótipos rápidos e ‘porco’ e nada mais. Software criado usando este modelo vai ser 
pequeno, curto em sutilezas da interface do usuário, e idiossincrático1. 
 
Figura 1 – Modelo de código e correção. 
 
Esta é uma excelente maneira de fazer protótipos rápidos, ‘porcos’ e curtos, 
programas únicos. É útil para validar decisões de arquitetura e de mostrar uma 
versão rápida de um design de interface do usuário. Use-o para compreender o 
problema maior que você está trabalhando. 
 
 
 
 
 
 
 
1
 Peculiar e pessoa, muito íntimo e que só a própria pessoa entenderia. 
3 
 
 
2.2 PROJETO ESTRUTURADO 
 
 
É a primeira categoria de metodologias de desenvolvimento de sistemas. 
Estas metodologias tornaram-se dominante na década de 1980, substituindo o 
anterior, ad hoc2, abordagem indisciplinado. Metodologias de projeto estruturadas 
adotam uma abordagem formal passo-a-passo para a CVDS que se move 
logicamente de uma fase para outra. 
 
 
2.2.1 Desenvolvimento em Cascata 
 
 
O primeiro e mais tradicional dos modelos de processos orientados a projeto 
é o modelo em cascata, conforme mostra o diagrama da Figura 2. Foi criado em 
1970 por Winston Royce, aborda todas as fases do ciclo padrão de vida. Exige uma 
documentação detalhada em cada fase, juntamente com comentários, o 
arquivamento dos documentos, terminar a transição em cada fase do processo, 
gerenciamento de configuração e gerenciamento próximo de todo o projeto. 
O projeto estruturado também introduziu o uso de modelagem formal ou 
técnicas de diagramação para descrever os processos básicos de negócios e os 
dados que os suportam. O projeto estruturado tradicional utiliza um conjunto de 
diagramas para representar os processos e um conjunto separado de diagramas 
para representar os dados. O analista de sistemas deve decidir sobre qual conjunto 
desenvolver primeiro e usar como o núcleo do sistema – modelo de diagramas de 
processo ou modelo de diagramas de dados. Há muito debate sobre quais devem vir 
em primeiro lugar, os processos ou os dados, porque ambos são importantes para o 
sistema. 
As duas principais vantagens da abordagem projeto estruturado em cascata: 
 Identifica os requisitos do sistema muito antes de a programação começa 
 Minimiza mudanças nos requisitos como o produto do projeto. 
As duas desvantagens principais são:2
 Direta, pontual, eventual, 
4 
 
 
 O desenho deve ser completamente especificado antes que a programação 
comece. 
 Um longo período de tempo decorrido entre a conclusão da proposta do sistema 
na fase de análise e a entrega do sistema (geralmente vários meses ou anos). 
 
Figura 2 – Modelo em Cascata. 
 
Um sistema pode também exigir retrabalho significativo porque o ambiente 
de negócios mudou desde o momento em que a fase de análise ocorreu. Quando as 
mudanças ocorrem, significa voltar para as fases iniciais e após a mudança através 
de cada uma das fases subsequentes, por sua vez. 
 
 
2.2.2 Retornar a Cascata 
 
 
A primeira coisa que acontece com o modelo cascata é que isso muda na 
cascata com feedback. Esta é uma admissão de que uma cascata em linha reta não 
funciona e que você precisa da capacidade de retornar em uma fase anterior, 
quando você descobre um problema na fase atual. 
A modelo cascata com feedback, apresentada na Figura 3, reconhece que 
você começa a trabalhar com requisitos, projeto, plano de teste incompletos e assim 
por diante. Também constrói explicitamente a ideia que você terá que voltar às 
5 
 
 
etapas anteriores do processo quando novas informações sobre o seu projeto são 
descobertas. As novas informações podem ser novos requisitos, requisitos 
atualizados, falhas de projeto, defeitos nos planos de teste e afins. Qualquer uma 
dessas exige que você revisite uma etapa anterior do processo para corrigir o 
problema. 
 
 
Figura 3 – Modelo de Cascata com Feedback. 
 
Este modelo de processo ainda é bastante rígido, e tem as mesmas 
vantagens de um modelo em cascata quando se trata de novos projetos e equipes 
inexperientes. As duas principais desvantagens com o modelo cascata com 
feedback são: 
 Que torna mais difícil saber quando terminou. 
 Ele mexe com o seu cronograma, porque em qualquer fase pode haver 
mudanças inesperadas de volta a uma fase anterior do desenvolvimento. 
 
 
2.2.3 Desenvolvimento Paralelo 
 
 
A metodologia de desenvolvimento paralelo, mostrada na Figura 4, tenta 
resolver o problema de atrasos entre a fase de análise e a entrega do sistema. Em 
vez de fazer projeto e implementação em sequência, ele executa um projeto geral 
para todo o sistema e depois divide o projeto em uma série de subprojetos distintos 
que podem ser projetados e implementados em paralelo. Uma vez que todos os 
6 
 
 
subprojetos estejam completos, há uma integração final das partes separadas, e o 
sistema é entregue. 
A principal vantagem desta metodologia é que ela pode reduzir o tempo de 
planejamento para entregar um sistema. Contudo, a abordagem ainda sofre 
problemas causados pela documentação de papel. Também adiciona um novo 
problema: Às vezes os subprojetos não são completamente independentes; 
decisões de projeto feitas em um subprojeto podem afetar os outros, e o fim do 
projeto pode exigir esforços de integração significativos. 
 
 
Figura 4 – Modelo de desenvolvimento paralelo. 
 
 
2.3 DESENVOLVIMENTO RÁPIDO DE APLICATIVOS (RAD) 
 
 
Uma segunda categoria de metodologias inclui o desenvolvimento rápido de 
aplicativos (RAD). Trata-se de uma nova classe de metodologias de 
desenvolvimento de sistemas que surgiram na década de 1990. Metodologias 
baseadas em RAD tentam resolver os pontos fracos de metodologias de projeto 
estruturadas, ajustando as fases CVDS para obter alguma parte do sistema 
desenvolvido rapidamente e nas mãos dos usuários. Desta forma, os usuários 
podem compreender melhor o sistema e sugerir revisões que trazem o sistema mais 
próximo do que é necessário. 
7 
 
 
A maioria das metodologias baseadas em RAD recomendam que os 
analistas utilizem técnicas especiais e ferramentas de computador para acelerar a 
análise, projeto e fases de implementação, tais como ferramentas CASE, sessões 
de joint application design (JAD), linguagens de programação visual de 4ª geração 
que simplificam e aceleram a programação (Visual Basic e Delphi), e geradores de 
código que automaticamente produzem programas de especificações de projeto. A 
combinação das fases alteradas do ciclo de vida e a utilização dessas ferramentas e 
técnicas melhoram a velocidade e qualidade do desenvolvimento de sistemas. No 
entanto, há um possível problema sutil com metodologias baseadas em RAD: gestão 
de expectativas dos usuários. Devido ao uso das ferramentas e técnicas que podem 
melhorar a velocidade e a qualidade de desenvolvimento de sistemas, as 
expectativas dos usuários de que é possível pode mudar drasticamente. Como um 
usuário compreende melhor a tecnologia da informação, os requisitos de sistemas 
tendem a se expandir. Este era um problema menor quando se utiliza metodologias 
que gastam bastante tempo na documentação de requisitos. 
 
 
2.3.1 Desenvolvimento em Fase 
 
 
 Uma metodologia de desenvolvimento baseado em fase, apresentando na 
Figura 5, quebra um sistema global em uma série de versões, que são 
desenvolvidas sequencialmente. A fase de análise identifica o conceito geral do 
sistema, e a equipe de projeto, usuários e patrocinador do sistema, então, 
classificam os requisitos em uma série de versões. Os requisitos mais importantes e 
fundamentais são empacotados para a primeira versão do sistema. A fase de 
análise, em seguida, leva ao projeto e implementação, mas apenas com o conjunto 
de requisitos identificados para a versão 1. 
Uma vez que a versão 1 é implementada, o trabalho começa na versão 2. 
Análise adicional é realizada com base nos requisitos previamente identificadas e 
combinadas com novas ideias e questões que surgiram a partir da experiência dos 
usuários com a versão 1. Assim que a versão 2 for projetada e implementada, e 
começa a trabalhar imediatamente na próxima versão. Este processo continua até 
que o sistema está completo. 
8 
 
 
Tem a vantagem de obter rapidamente um sistema útil nas mãos dos 
usuários. Embora o sistema não execute todas as funções que os usuários 
precisam, começa a proporcionar valor de negócio mais cedo do que se o sistema 
fosse entregue após a conclusão, como é o caso com as metodologias cascata e 
paralela. Da mesma forma, os usuários começam a trabalhar com o sistema mais 
cedo, e são mais propensos a identificar exigências adicionais importantes mais 
cedo do que com situações de projetos estruturados. 
A principal desvantagem é que os usuários começam a trabalhar com 
sistemas que são intencionalmente incompletos. É fundamental identificar as 
características mais importantes e úteis e incluí-las na primeira versão e gerenciar as 
expectativas dos usuários ao longo do caminho. 
 
Figura 5 – Metodologia de desenvolvimento em fase. 
 
 
2.3.2 Prototipação 
 
 
A metodologia baseada em prototipação realiza as fases de análise, projeto, 
e implementação ao mesmo tempo, e todas as três fases são realizadas 
9 
 
 
repetidamente em um ciclo até que o sistema seja concluído, como ilustrado na 
Figura 6. O primeiro protótipo é geralmente a primeira parte do sistema que é usado. 
Isso é mostrado aos usuários e ao patrocinador do projeto, que fornecem 
comentários. Estes comentários são usados para reavaliar, reformular e 
reimplementar um segundo protótipo, que fornece mais algumas funcionalidades. 
Esse processo continua em um ciclo até que os analistas, usuários e patrocinadores 
concordem que o protótipo oferece funcionalidade suficiente para ser instalado e 
utilizado na organização. Depois o protótipo (agora chamado de sistema) é 
instalado, o refinamento ocorre até que seja aceito como o novo sistema. 
 A vantagem de uma metodologiabaseada em protótipos: 
 Fornece muito rapidamente um sistema com o qual os usuários podem interagir, 
mesmo que não esteja pronto para uso organizacional de primeirar. 
 Tranquiliza os usuários que a equipe do projeto está trabalhando no sistema 
 Ajuda a refinar mais rapidamente as necessidades reais. 
 
Figura 6 – Metodologia baseada em prototipação. 
 
Muitas vezes, o protótipo passa por mudanças tão significativas que muitas 
decisões iniciais do projeto se tornam pobres. Isto pode causar problemas no 
desenvolvimento de sistemas complexos porque questões fundamentais e 
problemas não são reconhecidos até o processo de desenvolvimento. 
 
 
 
10 
 
 
2.3.3 Prototipagem Descartável 
 
 
Metodologias baseada em protótipos descartáveis são semelhantes aos de 
metodologias baseadas em protótipos na medida em que incluem o 
desenvolvimento de protótipos; no entanto, os protótipos descartáveis são feitos 
num ponto diferente no CVDS. Estes protótipos são utilizados para um propósito 
muito diferente do que os anteriormente discutidos, e têm uma aparência muito 
diferente. 
 Têm uma fase de análise relativamente completa (reune informações e 
desenvolve ideias para concepção do sistema). 
 Cada característica sugerida é examinada através da análise, projeto e 
construção de um protótipo de projeto. 
Um protótipo de projeto não é um sistema de trabalho; é um produto que 
representa uma parte do sistema que precisa de refinamento adicional, e que 
contém detalhes apenas o suficiente para permitir aos usuários compreender as 
questões em consideração. 
Um sistema desenvolvido usando este tipo de metodologia depende de 
vários protótipos durante as fases de análise e projeto. Cada um dos protótipos é 
utilizado para minimizar o risco associado ao sistema, confirmando que as questões 
importantes sejam entendidas antes que o sistema real esteja construído. Uma vez 
que as questões estejam resolvidas, o projeto progride em projeto e implementação. 
Neste ponto, os protótipos de projeto são jogados fora, que é uma diferença 
importante entre essa metodologia e metodologia de protótipos, em que os 
protótipos evoluem para o sistema final. 
Metodologias baseadas em protótipos descartáveis equilibram os benefícios 
das fases de análise e projeto bem pensada com as vantagens da utilização de 
protótipos para refinar questões fundamentais antes de um sistema estar construído, 
como mostra a Figura 7. Pode levar mais tempo para entregar o sistema final, em 
comparação com metodologias baseadas em protótipos, mas este tipo de 
metodologia geralmente produz sistemas mais estáveis e confiáveis. 
 
11 
 
 
 
Figura 7 – Metodologia baseada em protótipos descartáveis. 
 
 
2.3.4 Modelo de Evolução Incremental 
 
 
A maneira tradicional de implementação do modelo incremental é conhecida 
como prototipagem evolutiva. Na prototipação evolucionária, prioriza os requisitos 
como eles são recebidos e produz uma sucessão de cada vez mais rica em recursos 
de versões do produto. Cada versão é refinada usando feedback de clientes e os 
resultados da integração e testes do sistema. Este é um excelente modelo para um 
ambiente de requisitos de mudança ou ambíguo, ou com um domínio de aplicação 
pouco compreendido. Este é o modelo que evoluiu para os modernos processos de 
desenvolvimento ágeis. 
A Figura 8 ilustra o modelo de evolução incremental ou prototipagem 
evolutiva. 
 
 
2.4 DESENVOLVIMENTO ÁGIL 
 
 
Estas metodologias centradas em programação têm poucas regras e 
práticas, as quais são bastante fáceis de seguir. Eles se concentram na 
racionalização do CVDS, eliminando grande parte da modelagem e sobrecarga de 
documentação e o tempo gasto nessas tarefas. A abordagem ao desenvolvimento 
ágil é tipicamente utilizado em conjunto com metodologias orientadas a objeto. 
 Necessita menos documentação e menos controles de processo. 
12 
 
 
 
Figura 8 – Modelo de evolução incremental. 
 
 Destinada a projetos de software de pequeno e médio porte e equipes menores 
de desenvolvedores. 
 Permite que as equipes de desenvolvedores se ajustem rapidamente às 
mudanças nos requisitos e exigências dos clientes. 
 Propõe liberar o software concluído muito mais rapidamente do que os modelos 
orientados a plano. 
 
 
2.4.1 Programação Total (XP) 
 
 
Programação total (eXtreme Programming) foi criada por volta de 1995 por 
Kent Beck e Ward Cunningham. XP é uma maneira leve, eficiente, de baixo risco, 
flexível, previsível, científica, e divertida para desenvolver software. 
XP conta com as seguintes ideias fundamentais – comunicação, 
simplicidade, feedback e coragem: 
 Envolvimento pesado do cliente: XP exige que um representante do cliente seja 
parte da equipe de desenvolvimento e esteja no local em todos os momentos. O 
13 
 
 
representante do cliente trabalha com a equipe para criar o conteúdo de cada 
interação do produto, e cria todos os testes de aceitação para cada liberação 
provisória. 
 Teste unitário contínuo: XP chama para os desenvolvedores escreverem os 
testes unitários para todos os novos recursos antes de qualquer código ser 
escrito. Desta forma, os testes, é claro, inicialmente falharão, mas dá ao 
programador uma métrica clara para o sucesso. Quando todos os testes unitários 
passarem, terminou de implementar o recurso. 
 A programação em pares: XP exige que todo o código seja escrito por pares de 
programadores. Um escreve o código, enquanto o outro captura erros de 
digitação, faz sugestões, pensa sobre o projeto e testes, e assim por diante. A 
dupla muda os lugares periodicamente (a cada 30 minutos ou assim, ou quando 
um deles acha que ele tem uma melhor forma de implementar um pedaço de 
código). Oferece à equipe uma oportunidade de refatorar código existente - 
reprojetá-lo para torná-lo o mais simples possível, enquanto ainda atende aos 
requisitos do cliente. 
 Ciclos curtos de iteração e lançamentos frequentes: XP normalmente usa ciclos 
de lançamento no intervalo de poucos meses e cada lançamento é composto de 
várias iterações, cada um na ordem de 4 a 6 semanas. XP também exige 
constante integração e construção do produto. Em um projeto XP, integrações e 
construções podem acontecer várias vezes ao dia. 
XP tenta minimizar riscos, controlando as quatro variáveis de 
desenvolvimento de software: custo, tempo, recursos e qualidade. 
XP descreve quatro atividades que são a base da disciplina: codificação, 
testes, ouvir e projetar. 
O ciclo de vida XP contém todas as fases do ciclo de vida genérico, mas 
comprime as três fases intermediárias – projeto, código e teste – para uma fase de 
implementação única. A fase de produção é adicionada após a implementação para 
permitir que o código seja estabilizado antes do lançamento. 
 
 
 
 
14 
 
 
2.4.2 Scrum 
 
 
Scrum é uma metodologia ágil. Scrum deriva seu nome do rugby, onde um 
scrum é uma forma de reiniciar o jogo depois de uma infração às regras. O scrum 
usa os avante em uma equipe de rugby para tentar (re)conquistar o controle de bola 
e avance para a linha da baliza adversária. A ideia da metodologia Scrum ágil é que 
uma pequena equipe esteja unificada em torno de um objetivo único e se reúne para 
sprints de desenvolvimento que leve-os ao objetivo. 
 Vem da ideia de gestão de processo. 
 É uma variação da abordagem de desenvolvimento iterativo e incorpora muitos 
dos recursos do XP. 
 É uma abordagem mais de gestão que o XP e não define muitas das práticas de 
desenvolvimento detalhados como o XP faz, embora a maioria dos projetos 
Scrum utilize essas práticas. 
 Utilizaequipes com não mais de 10 desenvolvedores. Scrum enfatiza a eficácia 
de equipes pequenas e propriedade coletiva. 
 Scrum se caracterizada por sprint, uma iteração entre uma e quatro semanas. Às 
vezes um sprint pode terminar mais cedo, ou com menos funcionalidades do que 
foi proposto. Um sprint (corrida) sempre oferece um produto utilizável. 
 Os requisitos são encapsulados em dois pedaços: a lista de prioridades de todos 
os requisitos para o projeto, a lista priorizada de requisitos para o sprint atual. 
 Projetos Scrum é facilitado por um Scrum Master cujo trabalho é gerenciar os 
processos pendentes, executar reuniões diárias do Scrum, e proteger a equipe 
de influências externas durante o sprint. O Scrum Master geralmente não é um 
desenvolvedor. 
 Após cada sprint é realizada uma reunião de planejamento para o próximo sprint. 
Esta reunião também pode decidir se o projeto está concluído. 
 Após o último sprint programado é feito um sprint final que corrige eventuais 
falhas existentes, finaliza a documentação, e geralmente produz o código. 
Quaisquer requisitos deixados em reserva são transferidos para o próximo 
lançamento. 
 
 
15 
 
 
2.5 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE UNIFICADO 
 
 
É um processo de software orientado a casos de uso que utiliza a notação 
UML. Também é conhecido como o Rational Unified Process (RUP). É um processo 
popular de desenvolvimento de software baseada em UML. 
Consiste em núcleo de cinco fluxos trabalho, quatro fases e é iterativo. 
Cada ciclo atravessa todas as quatro fases e endereça o desenvolvimento do núcleo 
de um fluxo de trabalho. A Figura 9 ilustra essa metodologia. 
Os fluxos de trabalho e seus produtos são as seguintes: requisitos (modelo 
de casos e uso), análise, projeto, implementação e teste. 
Como o modelo espiral, o USDP é um processo orientado à risco. As fases 
do ciclo de vida do USDP são as seguintes: 
1. Iniciação: a ideia das sementes é desenvolvida para um nível suficiente para 
justificar entrar na fase de elaboração. 
2. Elaboração: a arquitetura de software é definido. 
3. Construção: o software é construído ao ponto dele estar pronto para a libertação 
para a comunidade de usuários. 
4. Transição: o software é entregue à comunidade de usuários. 
. 
 
Figura 9 – Processo RUP, baseado em UML. 
 
 
16 
 
 
2.6 SELEÇÃO DA METODOLOGIA DE DESENVOLVIMENTO APROPRIADA 
 
 
Por existirem muitas metodologias, o primeiro desafio enfrentado pelos 
analistas é selecionar qual delas usar. Escolher uma metodologia não é simples, 
porque nenhuma metodologia é sempre melhor. Muitas organizações têm padrões e 
políticas para orientar a escolha da metodologia. 
Um item importante é o grau de experiência da equipe de analistas. Muitas 
das metodologias RAD requerem o uso de "novas" ferramentas e técnicas que têm 
uma curva de aprendizagem significativa. Muitas vezes, essas ferramentas e 
técnicas aumentam a complexidade do projeto e necessita de um tempo extra para 
aprender. No entanto, uma vez que são adotadas e a equipe torna-se experiente, 
elas podem aumentar significativamente a velocidade em que a metodologia pode 
entregar um sistema final. 
 
 
2.7 EXERCÍCIOS 
 
 
1. (TJ-RJ – 2012) Dos diferentes modelos para o ciclo de vida de desenvolvimento 
de um software é correto afirmar que 
a) o modelo em espiral é o mais simples e o mais antigo. 
b) o modelo em cascata é o menos flexível e mais simples. 
c) a fase de especificação de requisitos pode estar ausente do modelo. 
d) a fase de implementação é sempre a última do modelo. 
e) o modelo em cascata é o mais recente e comple-xo. 
2. (TSE – 2012) Observe a figura, que representa uma ferramenta de processo, 
conhecida como Ciclo de Vida de Sistema. Devido ao encadeamento de uma 
fase com outra, esse modelo é conhecido como “cascata”. Observe. 
 
17 
 
 
Um das fases prevê a execução de atividades que envolvem a identificação e a 
descrição das abstrações fundamentais do sistema de software e suas relações 
e o estabelecimento de uma arquitetura geral para o sistema como um todo. 
Essa fase denomina-se 
a) definição de requisitos. 
b) projeto de sistema e software. 
c) implementação e teste de unidade. 
d) integração e teste de sistema. 
3. ( TSE – 2012) Observe um modelo de ciclo de vida para desenvolvimento de 
sistemas. Nessa abordagem, o desenvolvimento do produto de software é 
dividido em ciclos, sendo identificadas em cada ciclo, as fases de análise, 
projeto, implementação e testes. 
 
Este modelo é conhecido como ciclo de vida 
a) por prototipação em cascata. 
b) por estágios em módulos. 
c) iterativo e incremental. 
d) iterativo e incremental. 
4. (UDESC – 2010) Identifique se são verdadeiras ( V ) ou falsas ( F ) as seguintes 
afirmativas, com relação a ciclo de vida de software: 
( ) 
Pode-se considerar que na etapa de projeto ocorre a modelagem do 
domínio do problema. 
( ) 
Pode-se considerar que na etapa de análise ocorre a modelagem do 
domínio do negócio. 
( ) O modelo de ciclo de vida espiral prevê análise de riscos. 
( ) 
Os modelos de ciclo de vida espiral e incremental prevêem 
desenvolvimento cíclico. 
5. (SAD-PE – 2010) Um desenvolvedor de software foi contratado por uma empresa 
de software, mas ainda não tem informações acerca do modelo de 
desenvolvimento, do modelo de ciclo de vida ou do processo de desenvolvimento 
de software sob o qual se estruturam as atividades da organização. O 
desenvolvedor, no entanto, ao chegar às dependências da empresa, no seu 
primeiro dia de trabalho, começou a observar alguns comportamentos 
desempenhados pelos seus colegas. Tratando tais comportamentos como 
18 
 
 
evidências do desempenho de um processo aderente a determinado modelo, o 
desenvolvedor registrou algumas proposições acerca do modelo empregado na 
empresa. 
A respeito da situação acima, em cada uma das opções a seguir, é apresentada 
uma evidência coletada pelo desenvolvedor, que deve ser analisada 
individualmente, independentemente das demais evidências coletadas. Assinale 
a opção em que a conclusão de evidência é coerente com o que estabelece o 
corpo de conhecimento da engenharia de software acerca desse tema. 
a) Os requisitos do software da organização são, detalhadamente, descritos por 
meio de fórmulas e diagramas, usando-se notações matemáticas embasadas 
na teoria dos conjuntos, relações e funções, e no cálculo de predicados. 
Portanto, a empresa usa métodos ágeis. 
b) O gerente geral de projetos da empresa decidiu, junto a um cliente, realizar 
algumas modificações nos requisitos de um produto desoftware que já se 
encontrava na fase de testes e comprometeu-se a incluir tais requisitos na 
próxima liberação do produto. Essa decisão permite inferir que o modelo de 
desenvolvimento de software empregado não é do tipo cascata. 
c) Imediatamente após ter testado um protótipo evolucionário, um dos colegas 
da empresa iniciou a produção de uma lista de riscos aos quais o projeto está 
sujeito. Dessa forma, a empresa não utiliza um modelo de ciclo de vida 
embasado no espiral. 
d) Todos os colegas com os quais o desenvolvedor teve contato lhe informaram 
que desenvolvem testes unitários para os módulos que desenvolvem, 
realizam programação em pares e, periodicamente, fazem refatoração de 
código. Nesse caso, a empresa não utiliza o modelo de programação 
extrema. 
e) A empresa dispõe de processo bem estabelecido para medição e análise da 
qualidade dos processos de software e produtos desenvolvidos, não 
ocorrendo o mesmo com processos de gerenciamento de acordo com os 
vários fornecedores da empresa. Assim,a empresa tem chances de estar 
aderente ao CMMI, no nível de maturidade 2. 
6. (TRANSPETRO – 2011) Na Engenharia de Software, há diversos modelos de 
ciclo de vida, definidos com variados níveis de formalidade. O modelo 
a) cascata (ou clássico) é adequado para controlar riscos e requisitos voláteis 
durante o desenvolvimento do sistema. 
b) codificação e correção (code and fix) é adequado para alcançar um bom nível 
de manutenibilidade do sistema. 
c) prototipagem descartável é adequado para descartar a fase de levantamento 
de requisitos do sistema a ser desenvolvido. 
d) prototipagem evolutiva entrega uma versão inicial do sistema, que considera 
requisitos já definidos com o cliente. 
e) espiral é inadequado quando são necessários o uso de protótipos durante a 
validação do sistema e o reúso de software. 
19 
 
 
7. (BDMG – 2011) O modelo de ciclo de vida de processo de software cujos 
principais subprocessos são executados em estrita sequência, o que permite 
demarcá-los como pontos de controle bem definidos, é denominado: 
a) Espiral. 
b) Cascata. 
c) Prototipagem evolutiva. 
d) Dirigidos por prazo. 
8. (TRT-MT – 2011) Considere: 
I. Modificações devem ser ajustadas facilmente em módulos isolados e fáceis de 
encontrar. Se não atendem a isso, um reprojeto deverá ser necessário. 
II. Modificações de tabelas devem ser especialmente fáceis de fazer. Se qualquer 
modificação não é rápida e fácil de ser feita, indica-se a realização de um 
reprojeto. 
III. Modificações devem ser fáceis para serem feitas na forma de iterações. Se 
elas não são, haverá um problema básico tal como um projeto falho ou uma 
proliferação de correções. 
No contexto das bases para direcionar a implementação e análise do processo 
iterativo e incremental, está correto o que se afirma em 
a) I e III, apenas. 
b) III, apenas. 
c) I e II, apenas. 
d) II e III, apenas. 
e) I, II e III. 
9. (CFA – 2010) No modelo de desenvolvimento em espiral, cada loop da espiral 
representa uma fase do processo de software. A importante distinção entre este 
modelo e os demais é a consideração em todos os ciclos da análise de 
a) Escopo. 
b) Requisitos. 
c) Implementação e teste. 
d) Riscos. 
10. (CFA – 2010) O modelo espiral para a Engenharia de Software foi desenvolvido 
acrescentando-se novos elementos as melhores características de outros 
modelos. Segundo o modelo espiral, a determinação dos objetivos, alternativas e 
restrições está relacionada à atividade de 
a) análise de risco. 
b) planejamento. 
c) engenharia. 
d) avaliação feita pelo cliente. 
11. (AL-RR – 2010) Das seguintes informações sobre modelos de ciclos de vida de 
desenvolvimento de software, é INCORRETO afirmar: 
a) O modelo de ciclo de vida em espiral divide o desenvolvimento do software 
em iterações. 
b) O modelo de ciclo de vida em espiral é orientado a reduzir os riscos do 
projeto. 
20 
 
 
c) No modelo de ciclo de vida em cascata, as etapas acontecem de maneira 
seqüencial. 
d) O modelo de ciclo de vida em cascata permite instalar no final de cada fase 
uma versão do software no cliente. 
e) O modelo de prototipagem evolucionária permite que desde muito cedo se 
ganhe uma melhor percepção dos requisitos do sistema. 
12. (UFF – 2009) Em relação aos ciclos de vida do software, o desenvolvimento de 
sistemas por meio de ciclo de vida iterativos garante ao sistema: 
a) atualização contínua. 
b) legalidade. 
c) segurança. 
d) legibilidade. 
e) utilização mínima de recursos. 
13. (BAHIAGÁS – 2010) No modelo em espiral do processo 
de software cada loop na espiral representa 
a) uma disciplina de requisitos. 
b) um enfoque de banco de dados. 
c) uma tomada de decisão. 
d) uma fase do processo. 
e) um ciclo de programa. 
14. (ELETROBRÁS – 2010) A figura abaixo representa, simplificadamente, as fases 
do Modelo de Ciclo de Vida Cascata. 
 
Dentre as diversas características desse modelo, afirma-se que 
a) existe um protótipo do sistema, ao final de cada fase, cada vez mais 
completo, que permite ao cliente avaliar o produto. 
b) nenhuma fase é terminada até que a sua documentação tenha sido 
completada e seus produtos aprovados pelo grupo de garantia da qualidade. 
c) o custo de modificação do sistema é praticamente o mesmo, independente 
da fase em que o projeto esteja. 
d) as fases podem se sobrepor, para acelerar o projeto. 
e) datagramas de fluxo de dados ou diagramas UML são utilizados como 
técnicas gráficas para se comunicar com seus clientes. 
15. (ELETROBRÁS – 2010) O gerenciamento de grande quantidade de informação 
na construção de sistemas pode ser contornada usando-se a técnica de 
refinamentos sucessivos, utilizada no modelo de Ciclo de Vida Iterativo e 
Incremental. A construção de sistemas, com base nesse modelo de ciclo de vida, 
21 
 
 
a) é dividida em, no máximo, 7 incrementos, com 7 iterações cada, devido à 
restrição da Lei de Miller. 
b) tem seus incrementos trabalhados simultaneamente, acelerando o 
desenvolvimento do sistema. 
c) contém atividades que podem exigir trabalho, em maior ou menor grau, em 
todos os incrementos planejados. 
d) define que as atividades de testes sejam realizadas no último incremento, 
que é planejado exclusivamente para tal propósito. 
e) deve ter a mesma quantidade de iterações em todos os incrementos 
planejados. 
16. (ELETROBRÁS – 2010) O termo Modelo de Ciclo de Vida é utilizado para 
descrever um grupo de atividades e a forma como elas se relacionam. 
Considerando o Modelo de Ciclo de Vida de Sistemas por Prototipagem 
Evolucionária, afirma-se que 
a) os clientes não têm acesso a uma visualização dos progressos do 
desenvolvimento. 
b) é possível determinar com exatidão o tempo que o projeto irá demorar. 
c) não deve ser utilizado quando os requisitos mudam rapidamente e o cliente 
está relutante em aceitar um conjunto de requisitos. 
d) não há uma forma de saber de antemão o número de iterações que serão 
necessárias. 
e) apenas a fase final gera um produto que não é um documento. 
17. (ELETROBRÁS – 2010) Uma fábrica de software utiliza um ciclo de vida de 
desenvolvimento de sistemas que contempla um conjunto sequencial de ações 
de desenvolvimento, desde o diagnóstico do problema até os testes necessários 
à implementação. Além disso, nada está terminado até que todas as fases 
estejam completas. Esse ciclo de vida é conhecido como 
a) XP. 
b) Cascata. 
c) SCRUM. 
d) Continuum. 
e) Espiral. 
18. (CETESB – 2009) Considere um sistema cujos requisitos de interface são 
definidos apenas quando o cliente realiza um test-drive na aplicação e aprova 
essa interface. Assinale a alternativa que apresenta o modelo mais adequado 
para o desenvolvimento da interface desse sistema. 
a) Ágil. 
b) Cascata. 
c) Iterativo incremental. 
d) Prototipação. 
e) Rapid Application Development. 
19. (INMETRO – 2009) Assinale V (verdadeiro) ou F (falso) para as afirmações 
abaixo: 
( ) Em um ciclo de vida, com base em componentes de software, as 
22 
 
 
atividades de busca, avaliação, adaptação e testes de componentes 
ocorrem basicamente após as fase de desenho e antes da fase de 
testes do sistema de software. 
( ) As técnicas de refatoração de código compreendem, entre outras, a 
remoção de números mágicos e a introdução de padrões de 
desenho. 
( ) As técnicas, os métodos e as ferramentas classicamente associados 
às fases do modelo de ciclo de vida em cascata, na metodologia 
RUP, estão melhor distribuídos ao longo das disciplinas do que ao 
longo das fases do modelo. 
 
20. (TRT-SE – 2010) À medida que se avança pelo modelo ocorre uma iteração eo 
software evolui para estágios superiores, normalmente com aumento da 
complexidade. Cada iteração está provida das atividades determinadas pelos 
quadrantes planejamento, avaliação de alternativas e riscos, desenvolvimento do 
software e avaliação do cliente. No ciclo de vida de desenvolvimento de software, 
trata-se da propriedade do modelo 
a) Cascata. 
b) Incremental. 
c) Espiral. 
d) Prototipação. 
e) Balbúrdia. 
 
 
2.8 REFERÊNCIA BIBLIOGRÁFICA 
 
 
DENNIS, Alan; WIXOM, Barbara; TEGARDEN, David. System Analysis Design 
UML Version 2.0. 3rd ed. Hoboken: John Wiley & Sons, 2009 p. 6-29. 
 
GOMAA, Hassan. Software Modeling and Design. 1st ed. Cambridge: Cambridge 
University Press, 2011 p. 29-40. 
 
DOOLEY, John. Software Development and Professional Practice. 1st. ed. New 
York: Apress, 2011 p. 7-25

Continue navegando