1 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ático 1. 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 hoc 2, 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,
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. 3 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
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. 4 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
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. 6
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
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. 8 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. 9 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)
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 10
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. 11
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.. 12 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.
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. 13 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 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, 14
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. 15
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. 16
14. (ELETROBRÁS 2010) A figura abaixo representa, simplificadamente, as fases do Modelo de Ciclo de Vida Cascata. 17 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.
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. 18
19 d) Prototipação. e) Balbúrdia. REFERÊNCIA BIBLIOGRÁFICA DENNIS, Alan; WIXOM, Barbara; TEGARDEN, David. System Analysis Design UML Version 2.0. 3 rd ed. Hoboken: John Wiley & Sons, 2009 p. 6-29. GOMAA, Hassan. Software Modeling and Design. 1 st Cambridge University Press, 2011 p. 29-40. ed. Cambridge: DOOLEY, John. Software Development and Professional Practice. 1 st. ed. New York: Apress, 2011 p. 7-25