METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS · Uma metodologia de desenvolvimento baseado em fase...

1

HTTP://erinaldosn.wordpress.com

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.

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.

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.

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.

1 Peculiar e pessoa, muito íntimo e que só a própria pessoa entenderia.

2


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.

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.

Desenvolvimento em Cascata

O primeiro e mais tradicional dos modelos de processos orientados a

projeto é o modelo em cascata. 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 –

2 Direta, pontual, eventual,

3


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:

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).

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.

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 reconhece que você começa a

trabalhar com requisitos, projeto, plano de teste incompletos e assim por

4


diante. Também constrói explicitamente a ideia que você terá que voltar às

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.

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.

Desenvolvimento Paralelo

Metodologia de desenvolvimento paralelo 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

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.

5


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.

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.

Desenvolvimento em Fase

6


Uma metodologia de desenvolvimento baseado em fase 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.

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.

7


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 repetidamente em um ciclo até que o sistema seja concluído. 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 metodologia baseada 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.

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.

Prototipagem Descartável

8


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. 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.

Modelo de Evolução Incremental

A maneira tradicional de implementação do modelo incremental é

conhecida como prototipagem evolutiva. Na prototipação evolucionária, prioriza

9


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.

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.

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.

Programação Total (XP)

10


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 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.

Scrum

11


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.

Utiliza equipes 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.

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.

12


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.

.

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.

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.

13


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.

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.

14


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 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,

15


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.

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.

16


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.

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.

17


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,

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.

18


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 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

e o 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.

19


d) Prototipação.

e) Balbúrdia.

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

METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS · Uma metodologia de desenvolvimento baseado em fase...

Documents

Transcript of METODOLOGIAS DE DESENVOLVIMENTO DE SISTEMAS · Uma metodologia de desenvolvimento baseado em fase...