ANÁLISE E PROJETO DE SISTEMAS

TI EM EXERCÍCIOS P/ INSS Conhecimentos específicos - Formação em Tecnologia da Informação (TEINF)

Profa. Patrícia Lima Quintão www.pontodosconcursos.com.br 1 de 92

AULA 6 – ANÁLISE E PROJETO DE SISTEMAS

Olá pessoal, tudo bem!

Hoje trago para vocês a sexta aula do curso, com um Memorex complementar e muitas questões rs.. Espero que aproveitem!

“Sem o esforço da busca torna-se impossível a alegria da conquista”.

Embora muitos concurseiros o façam, não devemos iniciar um projeto de estudo sem algumas ATITUDES BÁSICAS.

Você até pode seguir adiante sem elas, mas com certeza terá grandes chances de desistir no decorrer da caminhada ou de gastar mais tempo do que o necessário.

Então, vamos conhecê-las desde já, e tomar consciência de que são importantes para que você alcance o sucesso não só nas provas de concursos, mas em qualquer etapa/projeto da sua vida.

Antes de falar sobre essas atitudes, é preciso que você tenha um objetivo claro e visão. O objetivo deve ser OTIMISTA e voltado para a realidade. A partir daí é preciso AÇÃO, pois apenas ela transforma a realidade.

Então, primeiramente, acredite no seu SONHO, no entanto, ele só acontece quando agimos, trabalhamos, nos esforçamos para sua concretização. Assim, no momento em que temos um objetivo a ser alcançado e começarmos a agir, é preciso as cinco qualidades seguintes, já mencionadas pelo mestre William Douglas, que são: COMPROMISSO, AUTODISCIPLINA, ORGANIZAÇÃO, ACUIDADE (prestar atenção nas coisas) e FLEXIBILIDADE (adaptação).

www.concurseirosunidos.org



No próximo post da minha página do Facebook irei detalhar cada uma delas (espero vocês por lá!). Continuem firmes nessa caminhada e ótimos estudos!

Um abraço,

Profa Patrícia Lima Quintão

Facebook: http://www.facebook.com/professorapatriciaquintao (Todo dia com novas dicas, desafios e muito mais, espero vocês por lá para CURTIR a página!)

Instagram: patriciaquintao

Conteúdo desta Aula Página

Memorex. 02

Lista de Questões Comentadas Nesta Aula. 21

Questões Apresentadas na Aula. 74

Gabarito. 92

MEMOREX – Extra – Aproveitem!

• Uma metodologia de processo genérica para engenharia de software estabelece cinco atividades metodológicas básicas, de acordo com Pressman, que são: comunicação, planejamento, modelagem, construção e entrega.

Fluxo de Processo

O fluxo de processo descreve como são organizadas as atividades metodológicas, bem como as ações e tarefas que ocorrem dentro de cada atividade em relação à sequência e ao tempo, como ilustrado nas figuras desta seção.

1)Fluxo de Processo Linear

Executa cada uma das cinco atividades metodológicas em sequência, começando com a de comunicação e terminando com a entrega (ou emprego, ou implantação).

Figura. Fluxo de Processo Linear. Fonte: Pressman (2011)

2)Fluxo de Processo Iterativo

Repete uma ou mais das atividades antes de prosseguir para a seguinte, conforme listado na próxima figura.



Figura. Fluxo de Processo Iterativo. Fonte: Pressman (2011)

3)Fluxo de Processo Evolucionário

Executa as atividades de forma “circular”. Cada volta pelas cinco atividades conduz a uma versão mais completa do software.

Figura. Fluxo de Processo Evolucionário. Fonte: Pressman (2011)

4)Fluxo de Processo Paralelo

Executa uma ou mais atividades em paralelo com outras atividades (como por exemplo a modelagem para um aspecto do software poderia ser executada em paralelo com a construção de um outro aspecto do software).

Figura. Fluxo de Processo Paralelo. Fonte: Pressman (2011)



Modelos de Processo de Software

Todos os modelos de processo de software, segundo Pressman (2011) podem acomodar as atividades metodológicas genéricas, aqui apresentadas, porém, cada um deles dá uma ênfase diferente a essas atividades e define um fluxo de processo que invoca cada atividade metodológica de forma diversa.

Há vários processos de desenvolvimento propostos. Bezerra (2007) destaca que é um consenso na comunidade de desenvolvimento de software o fato de que não existe o melhor processo de desenvolvimento, aquele que melhor se aplica a todas as situações de desenvolvimento. Segundo o autor, cada processo tem suas particularidades em relação ao modo de arranjar e encadear as atividades de desenvolvimento.

Há vários modelos de processo de software propostos, vamos ao estudo dos principais, importantes para a prova.

• Modelo em Cascata

Também chamado de clássico, ou linear, é o mais tradicional processo de desenvolvimento de software.

Esse modelo sugere uma abordagem sequencial e sistemática para o desenvolvimento de software, aplicando as atividades de maneira linear. Em cada fase desenvolvem-se artefatos (produtos de software) que servem de base para as fases seguintes.

Vide figura proposta por Pressman (2011) para esse modelo.

Figura. Modelo Cascata, segundo Pressman (2011)

Segundo proposta de Eduardo Bezerra, o modelo do ciclo de vida clássico da engenharia de software é dividido em seis atividades. São elas:



Em seguida, a proposta de Kruchten (2003).

O modelo em Cascata possui como vantagem principal a simplicidade para a sua aplicação e gerência.

No entanto, algumas desvantagens podem ser observadas:

• projetos reais raramente seguem este fluxo sequencial.

• dificuldade do cliente em declarar todas as suas necessidades no início do projeto.

• demora em apresentar resultados ao cliente.

Uma variação do modelo cascata, destacada por Pressman (2011) é o modelo V. Segundo o autor, à medida que a equipe de software desce em direção ao lado esquerdo do V, os requisitos básicos do problema são refinados em representações progressivamente cada vez mais detalhadas e técnicas do problema e de sua solução. Uma vez que o código tenha sido gerado, a equipe sobe o V, realizando uma série de testes que validem cada um dos modelos criados do outro lado do V.



Na realidade, segundo Pressman (2011) não existe diferença entre os modelos. O modelo V fornece uma maneira para visualizar como a verificação e as ações de validação são aplicadas ao trabalho de engenharia do ciclo de vida em Cascata.

Figura. Modelo V. Fonte: Pressman (2011)

• Modelo Incremental

Este modelo foi proposto como uma alternativa ao modelo em cascata, aplicando-o iterativamente, tendo como objetivo a elaboração de um produto operacional a cada incremento. Os primeiros incrementos são versões simplificadas do produto final, mas oferecem capacidades que servem ao usuário, além de servir como uma plataforma de avaliação.

Em cada iteração uma parte é concebida como a menor unidade que pode ser implementada e ainda assim fornecer alguma funcionalidade útil para os usuários.

Os modelos incrementais combinam elementos dos fluxos de processos lineares e paralelos.

Na figura seguinte, o modelo incremental aplica sequências lineares, de forma escalonada, à medida que o tempo vai avançando. Cada sequência linear gera “incrementais” (entregáveis/aprovados/liberados) do software.



Figura. Modelo Incremental. Fonte: Pressman (2011)

Este modelo possui como vantagem o fato de apresentar constantemente novas versões aos usuários. Pode ser aplicado também quando não houver mão-de-obra disponível para uma implementação completa, ou quando for necessário gerenciar riscos técnicos.

• RAD (Rapid Application Development - Desenvolvimento Rápido de Aplicação)

Trata-se de um modelo de processo de software incremental que enfatiza um ciclo de desenvolvimento curto. É uma adaptação “de alta velocidade” do modelo em cascata, no qual o desenvolvimento rápido é conseguido com o uso de uma abordagem de construção baseada em componentes.

Desvantagens: projetos grandes precisam de muitas equipes; exige comprometimento dos clientes e desenvolvedores; sistemas não modularizados são problemáticos; não é adequado para projetos com grandes riscos técnicos.



• Modelo Evolutivo (Modelo de Processo Evolucionário)

Produz uma versão cada vez mais completa do software a cada iteração.

• Prototipação (chamada também como Prototipagem)

Em algumas situações, o cliente consegue definir apenas um conjunto de objetivos gerais do software, não identificando claramente seus requisitos. Em uma situação dessas, a prototipagem pode ser empregada em conjunto com outros modelos para auxiliar no entendimento do sistema.

Os objetivos do software são estabelecidos na comunicação com o cliente. A partir daí, um protótipo descartável é elaborado com o intuito de facilitar a compreensão do sistema por parte dos usuários.

Apesar da prototipagem poder ser aplicada como um modelo, em geral ela é mais utilizada como uma técnica para entendimento do sistema. A próxima figura apresenta o esquema deste modelo.



Figura. O Paradigma da Prototipação. Fonte: Pressman (2011)

Vantagens da prototipagem:

• maior participação e comprometimento dos clientes e usuários; e

• os resultados são apresentados mais rapidamente.

Críticas:

• forte dependência das linguagens e ambientes utilizados, bem como da experiência da equipe;

• o cliente tende a considerar o protótipo como versão final, podendo comprometer a qualidade do projeto; e

• o desenvolvedor tende a fazer concessões na implementação, a fim de colocar um protótipo em funcionamento rapidamente. Estas concessões podem se tornar parte integrante do sistema.

• Modelo Espiral

No modelo Espiral, assume-se que o processo de desenvolvimento ocorre em ciclos, cada um contendo fases de avaliação e planejamento em que a opção de abordagem para a próxima fase (ou ciclo) é determinada.

Neste modelo acrescenta-se a Análise dos Riscos ao ciclo de vida para auxiliar as decisões a respeito da próxima iteração. A figura seguinte apresenta o esquema desse modelo.



Figura. O Modelo Espiral Típico. Fonte: Pressman (2011)

No modelo de processo de desenvolvimento em espiral, cada loop na espiral representa uma fase do processo de software. Este modelo exige a consideração direta dos riscos técnicos em todos os estágios do projeto e, se aplicado adequadamente, deve reduzir os riscos antes que eles se tornem problemáticos.

Apesar desse modelo reunir as melhores características dos outros, algumas críticas podem ser feitas:

• exige gerentes e técnicos experientes;

• uma vez que o modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, as tarefas gerenciais para acompanhamento e controle do projeto são mais complexas;

• é necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

• RUP (Rational Unified Process)

O Rational Unified Process (RUP) é um exemplo de modelo de processo de desenvolvimento baseado no Unified Process (Processo Unificado) desenvolvido pela Rational.

O RUP oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento. Sua meta é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um cronograma e de um orçamento previsíveis.

O Rational Unified Process é um processo de desenvolvimento iterativo e incremental, no qual o software não é implementado em um instante no fim do projeto, mas é, ao contrário, desenvolvido e implementado em partes. A cada iteração deste processo utiliza-se quatro fases, a saber: Concepção, Elaboração, Construção e Transição.



• Durante a Concepção ou Início (Inception), estabelece-se a lógica do domínio da aplicação para o projeto e decide o escopo do projeto. É aqui que se obtém o comprometimento do patrocinador do projeto para seguir adiante. Nesta fase compreende-se o problema da tecnologia empregada por meio da definição dos use cases mais críticos. Define-se aqui o caso de negócio e escopo do projeto.

• Na Elaboração (Elaboration) coleta-se requisitos mais detalhados, faz uma análise e um projeto de alto nível para estabelecer uma arquitetura básica, e cria um plano para a construção do sistema. Deve-se analisar o domínio do problema, estabelecer a arquitetura, desenvolver o plano do projeto e eliminar elementos de alto risco.

• A fase de Construção (Construction) consiste de várias iterações, nas quais cada iteração constrói software de qualidade de produção, testado e integrado, que satisfaz um subconjunto de requisitos de projeto. Cada iteração contém todas as fases usuais do ciclo de vida da análise, do projeto, da implementação e do teste. Desenvolve-se o software e prepara-se o mesmo para a transição para os usuários. Além do código, também são produzidos os casos de teste e a documentação.

• Mesmo com este tipo de processo iterativo, algum trabalho tem que ser deixado para ser feito no fim, na fase de Transição (Transition). Nesta fase são realizados os treinamentos dos usuários e a transição do produto para utilização. Este trabalho pode incluir também testes beta e ajuste de performance.

Os projetos variam de acordo com o volume de formalidade que eles têm. Projetos de muita formalidade têm muitos documentos formais a serem entregues, reuniões formais, encerramentos formais. Projetos de pouca formalidade podem ter uma fase de concepção que consiste de um bate-papo de uma hora com o patrocinador do projeto e um plano que cabe em uma folha de papel. Naturalmente quanto maior o projeto, mais formalidade precisa. O fundamental de cada fase ainda acontece, mas de formas bem diferentes.

Após a fase de Transição de uma iteração completa, o produto pode voltar a percorrer cada uma das fases para se produzir uma nova versão do produto.

Cada uma das quatro fases do RUP é dividida em iterações, onde cada uma delas é um ciclo completo de desenvolvimento resultando em uma versão de um produto executável que constitui um subconjunto do produto final. Cada iteração é organizada em fluxos de trabalho (workflows) de processo, com uma ênfase diferente em cada fase.

Os fluxos de trabalho de processo do RUP são:

• Gerenciamento de Projeto (Project Management);

• Modelagem Comercial ou de Negócio (Business Modeling);

• Requisitos ou Exigências (Requirements);

• Análise e Projeto (Analisys & Design);

• Implementação (Implementation);



• Testes (Test);

• Distribuição ou Entrega (Deployment);

• Gerência de Configuração e Mudanças (Configuration and Change Management); e

• Ambiente (Enviroment).

A figura ilustrada a seguir apresenta o relacionamento entre as fases e o esforço de desenvolvimento em cada fluxo de trabalho de processo.

O RUP é composto por nove disciplinas e quatro fases!!!!

Figura. Fases e disciplinas do RUP. Fonte: (KRUCHTEN, 2003)

Na figura, o eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo como se desdobra. Já o eixo vertical representa os fluxos essenciais do processo, que agrupa logicamente as atividades por natureza.

• Processo Ágil

A Engenharia de Software vem há anos criando técnicas de modelagem, projeto e desenvolvimento de sistemas. Dentre os desafios dos pesquisadores da área, pode-se citar a preocupação em desenvolver softwares com qualidade garantida, no prazo estabelecido e sem alocar recursos além do previsto. No entanto, muitas das metodologias criadas são consumidoras de muitos recursos, aplicando-se principalmente a grandes sistemas.



Como a Engenharia de Software ainda está evoluindo, novos modelos estão sendo apresentados, como: desenvolvimento ágil; dentre outros. Aqui merecem destaque o SCRUM e eXtreme Programming

SCRUM

O Scrum é um processo de desenvolvimento ágil de software baseado em grupos de práticas e papeis pré-definidos. Ele é um processo iterativo e incremental para gerenciamento de projetos e desenvolvimento de sistemas, em que cada sprint é uma iteração que segue um ciclo PDCA (Plan, Do, Check, Act) e entrega um incremento de software pronto.

Os principais papéis do Scrum são: Product Owner, Scrum Master e Scrum Team (equipe do projeto).

Não há como fazermos um mapeamento direto entre os papéis do Scrum e os papéis convencionais conhecidos. Não existe a figura única do Gerente de Projetos. Suas responsabilidades estão diluídas entre os papéis citados. Cada um conhece sua participação frente ao projeto e trabalha em conjunto para conseguir alcançar o goal definido.

Seus artefatos principais são: o Product Backlog (Produto Backlog) e Sprint Backlog – artefatos que representam seus requisitos/atividades, além de Burndown charts e impediment backlogs.

eXtreme Programming

A eXtreme Programming faz parte também de uma série de métodos denominados ágeis (agile). Estes métodos foram inicialmente considerados leves (lightweight) para diferenciá-los dos métodos tradicionais de desenvolvimento considerados pesados (heavyweight), os quais seriam baseados na produção de uma grande quantidade de documentação e modelos para guiar a programação.

Ao contrário dos métodos tradicionais que são orientados ao planejamento, previsibilidade e ao controle, os métodos ágeis são orientados à construção, testes e principalmente, às pessoas. As metodologias ágeis enfatizam os aspectos humanos, as relações pessoais, uma vez que buscam valorizar o pensamento criativo dos indivíduos envolvidos no projeto, em que o conhecimento é fator importante para o sucesso do projeto.

No desenvolvimento ágil a metodologia deve produzir conhecimento e não apenas documentação. Mas isto não significa que nos ambientes ágeis não exista documentação, apenas deixa de existir a filosofia de que “tudo tem que ser documentado” e sim documentar apenas o necessário uma vez que a documentação apenas auxilia e não guia o desenvolvimento.

Na próxima figura podemos comparar a XP ao modelo tradicional de desenvolvimento de software.



Como se vê na figura, o modelo em cascata estabelece uma ordenação linear no que diz respeito à realização das diferentes etapas, já o modelo iterativo é um modelo de processo de desenvolvimento que busca contornar algumas das limitações existentes no modelo cascata. Já a XP trabalha com iterações de menor tamanho possível, contendo os requisitos de maior valor para o negócio, sendo assim, a equipe produz um conjunto reduzido de funcionalidades e coloca em produção rapidamente de modo que o cliente já possa utilizar o software no dia-a-dia e se beneficiar dele.

Valores

Para implantar a XP é necessário que se norteie o trabalho baseado em quatro valores:

• Comunicação: é o principal valor da XP. Grande parte das técnicas da XP está baseada na comunicação, e se esta não for eficiente, pode causar problemas e atrasos no desenvolvimento do sistema.

• Simplicidade: a XP utiliza-se da simplicidade para implementar apenas aquilo que é suficiente para o cliente, não se procura fazer especulações sobre necessidades futuras, pois quase sempre são especulações errôneas, deixamos os problemas do futuro para o futuro.

• Feedback: o cliente deve receber o sistema o quanto antes, a fim de poder dar um feedback rápido, guiando assim o desenvolvimento do software.

• Coragem: é preciso muita coragem para mudar a maneira pela qual desenvolve-se sistemas. Colocar um sistema em produção assim que ele tenha valor para o cliente, fazer apenas o que se precisa para o momento e calcar o processo de análise principalmente na comunicação não é fácil, e precisa que a equipe esteja realmente decidida a mudar o seu processo de desenvolvimento.

Práticas

A XP é baseada em um conjunto de técnicas fundamentais (práticas), que podem ser aplicadas individualmente, cada uma delas gerando melhorias no processo de desenvolvimento, mas que funcionam melhor em conjunto, uma



vez que uma técnica reforça o resultado da outra. Apresenta-se a seguir uma descrição de cada prática.

• Cliente Presente (On-site customer)

Na XP todas as decisões sobre o rumo do projeto devem ser tomadas pelo cliente. Ele deve priorizar as tarefas, ser responsável pelos testes de aceitação, e, acima de tudo, orientar e tirar dúvidas dos desenvolvedores durante o processo de programação.

Se o cliente não puder estar junto dos desenvolvedores, algumas técnicas podem ser utilizadas, como, por exemplo, nomear um membro da equipe para representar o cliente. Também se podem agendar reuniões de acompanhamento com o cliente, pelo menos uma vez por semana. Nestas reuniões haverá muita discussão sobre prioridades, mas deve-se destinar uma parte significativa da mesma para que os programadores possam saber o que e como desenvolver.

• Jogo do Planejamento (The Planning Game)

O XP utiliza o planejamento para assegurar que a equipe de desenvolvimento esteja sempre trabalhando naquilo que irá gerar maior valor para o cliente a cada dia de trabalho. Este planejamento é feito diversas vezes ao longo do projeto, para que todos tenham a oportunidade de revisar as prioridades.

Na XP o planejamento é um processo contínuo, e o mesmo é constantemente refinado pelo cliente e pela equipe de desenvolvimento, deixando assim a metodologia bastante flexível e entregando para o cliente sempre o máximo valor pelo investimento dele.

• Pequenos Lançamentos (Small Releases)

Para que o cliente possa fornecer constantemente feedback sobre o andamento do sistema, fazendo possível que o jogo do planejamento (planning game) seja executado, é importante que o sistema tenha releases pequenos, a fim de ajustar o desenvolvimento às necessidades que vão surgindo no decorrer do processo.

Normalmente, trabalha-se com pequenas iterações gerando releases mais curtos, mas algumas empresas vêm suprimindo a etapa das iterações, lançando direto um release por semana.

Quanto menor o intervalo de tempo entre cada versão que o cliente recebe, mais fácil será corrigir eventuais problemas, pois não terá sido entregue uma quantidade muito grande de funcionalidades, e mais fácil será fazer algum ajuste no software para atender a uma mudança de requisitos. Além disso, o XP recomenda que o cliente busque selecionar as funcionalidades que mais vão gerar valor para ele, com isso fazemos com que o cliente tenha um retorno de investimento o mais cedo possível.

• Desenvolvimento Guiado pelos testes (Test First Design)

O desenvolvimento guiado pelos testes define que qualquer método de um objeto que possa falhar deve ter um teste automatizado que garanta o seu funcionamento.



• Integração Contínua (Continuous Integration)

Quando uma equipe desenvolve um software é comum que o software seja “quebrado” em algumas partes a fim de que cada desenvolvedor implemente a sua parte, esta visão é interessante porque assim cada desenvolvedor tende a se preocupar só com a sua parte do sistema o que reduz a complexidade do problema. Neste caso são definidas interfaces para comunicação entre estas partes para posterior agrupamento e formação de um software coeso. Porém é muito comum acontecerem erros na integração, estes erros acontecem geralmente por que:

� As interfaces definidas não foram respeitadas;

� Não houve compreensão por parte de um desenvolvedor da interface do outro;

� O sistema como um todo é pouco coeso.

Devido a estes erros e também da instabilidade das interfaces, por estarem sempre em constante mudança, a integração contínua se faz necessária para amenizar e até suprimir esses erros, uma vez que expõe todo o estágio atual de desenvolvimento, oferece feedback constante e estimula agilidade no desenvolvimento do software.

A técnica de integração contínua diz que o código desenvolvido por cada par de desenvolvedores deve ser integrado ao código base constantemente.

• Projeto Simples (Simple Design)

Kent Beck utiliza quatro regras básicas para definir simplicidade, são elas em ordem de prioridade:

1. O sistema (código e testes em conjunto) deve expressar tudo aquilo que você deseja comunicar.

2. O sistema não deve conter nenhum código duplicado.

3. O sistema deve ter o menor número de classes possível.

4. O sistema deve ter o menor número de métodos possível.

• Refatoração (Refactoring)

É o processo de mudar um sistema de software de tal forma que não se altera o comportamento externo do código, mas melhora sua estrutura interna. É um meio disciplinado de limpar o código e que reduz as possibilidades de introduzir erros. Em essência quando você refina o código, você melhora o projeto depois que este foi escrito. "Melhorar o projeto depois que foi escrito" é uma premissa do XP.

A técnica de refinamento do design é utilizada sempre com o intuito de simplificar o código. Refactoring significa reescrever o código, melhorando e simplificando o mesmo, sempre que se tiver oportunidade. O projeto do código vai sendo aos poucos melhorado através de modificações que o aprimorem. Estas modificações partem de um código fonte o qual passa em todos os testes, e devem levar a um código-fonte que continue passando em todos os testes.



• Programação em pares (Pair Programming)

Todo o código que vai para a produção é escrito por um par de programadores que utilizam uma mesma estação de trabalho ao mesmo tempo, ou seja, um computador, um teclado e dois desenvolvedores.

Na XP todo o código deve ser produzido por duas pessoas utilizando o mesmo computador. Enquanto um dos parceiros se preocupa com detalhes da implementação, ficando responsável pela digitação do código, o outro deve tentar ter uma visão mais ampla da rotina, imaginando as suas peculiaridades. Não apenas o código deve ser produzido por duas pessoas, como também todo o projeto da classe na qual vai se trabalhar.

• Propriedade Coletiva (Collective Ownership)

O código deve ser de propriedade de todos e todos devem ter permissão para alterar o que for necessário para que seu trabalho possa ser desenvolvido. Em estruturas onde determinadas rotinas são de “propriedade” de algumas pessoas, podem ocorrer atrasos no desenvolvimento devido à necessidade de que seja alterado algo nestas rotinas para que outras pessoas possam continuar com o seu trabalho.

• Padrões de Codificação (Coding Standards)

XP recomenda a utilização de padrões de codificação, que devem ser adotados no início do projeto com o consentimento de todos os desenvolvedores. Desta forma, qualquer desenvolvedor poderá ler o código com velocidade, sem se preocupar em compreender estilos de formatação especiais.

• Ritmo Sustentável (40 Hour Week)

Um dos grandes problemas que projetos de desenvolvimento de software enfrentam é o curto prazo de entrega do sistema. Com um prazo cada vez mais curto e sistemas cada vez mais complexos uma das alternativas dos desenvolvedores é o trabalho em excesso. As pessoas passam a trabalhar diariamente até mais tarde invadindo também finais de semana e feriados, porém trabalhar por longos períodos é contraproducente, e normalmente tende a piorar a situação.

• Metáfora (Metaphor)

Equipes XP mantêm uma visão compartilhada do funcionamento do sistema. Isto é feito através do uso de metáforas. Fazendo uso de metáforas podemos facilitar a explicação de qualquer aspecto dentro do projeto e ao mesmo tempo fixá-la com mais força na mente do ouvinte.

Utilizam-se metáforas para vários aspectos na XP, dentre eles procura-se criar uma visão comum sobre todo o projeto de forma simples e objetiva facilitando assim a comunicação entre toda a equipe, uma vez que serve de base para os padrões de codificação e entre a equipe e o cliente, visto que o cliente, na maioria das vezes, não entende os termos técnicos relacionados ao desenvolvimento e usados diversas vezes pelos desenvolvedores e equipe.



• Modelo Concorrente

Esse modelo, algumas vezes denominado engenharia concorrente, possibilita à equipe de software representar elementos concorrentes e iterativos de qualquer um dos modelos de processos aqui descritos. Como exemplo, a atividade de modelagem definida para o modelo espiral pode ser realizada invocando uma ou mais das seguintes ações de engenharia de software: prototipagem, análise e projeto (Pressman, 2011).

• Desenvolvimento Baseado em Componentes

Desenvolve aplicações a partir de componentes de software pré-empacotados (faz reuso de componentes de softwares já existente, para conseguir redução no tempo do ciclo de desenvolvimento, bem como redução no custo do projeto) (Pressman, 2011).

• Modelo de Métodos Formais

Engloba um conjunto de atividades que conduzem à especificação matemática formal do software.

APF – Análise de Ponto de Função

Técnica que permite medir a funcionalidade de um software ou aplicativo, sob a visão do usuário, a partir da descrição dos requisitos do usuário.

• É uma técnica de medição das funcionalidades fornecidas por um software do ponto de vista do usuário.

• Trata-se de um método padrão para MEDIR desenvolvimento de software de acordo com a perspectiva do USUÁRIO.

• Faz medição das funcionalidades fornecidas por um software do ponto de vista do usuário (Tamanho funcional).

Objetivos • Medir o tamanho das funcionalidades requisitadas e recebidas pelo usuário • Medir desenvolvimento e manutenção de software independente da

tecnologia. Por buscar independência da tecnologia utilizada para a construção do software, a APF independe da linguagem de programação utilizada.

Visão do Usuário • Usuário – qualquer pessoa ou coisa que interaja com a aplicação ou

especifique seus requisitos, como: Pessoa física; outra aplicação; Hardware; Ator em um caso de uso; Gestores de negócio que o software irá atender.

• Uma visão do usuário representa uma descrição formal das necessidades do negócio do usuário, na linguagem do usuário. • É uma descrição das funções do negócio. • É aprovada pelo usuário.



• Pode ser usada para contar pontos de função. Pode variar na forma física (ex., catálogo de transações, propostas, documento de requisitos, especificações externas, especificações detalhadas, manuais do usuário).

Componentes dos Pontos de Função (Importante) De acordo com o Manual de Práticas do IFPUG 4.2.1 temos cinco tipos de funções:

• Arquivo Lógico Interno (ALI) • Arquivo de Interface Externa (AIE) • Entrada Externa (EE) • Saída Externa (SE) • Consulta Externa (CE)

Etapas para Avaliação

� Etapa I - Identificação do TIPO DE CONTAGEM a ser utilizado - O quê vou medir?

Projeto de Desenvolvimento/Projeto de Manutenção/Projeto de Aplicação

� Etapa II - Definição da FRONTEIRA da aplicação - Quais os limites

do que vou medir? => Escopo do sistema objeto da avaliação.

� Etapa III - Contagem de pontos de função não ajustados - Como vou medir? Reflete o conjunto de funções disponibilizadas ao usuário. � O resultado da contagem nessa etapa são pontos de função brutos!

� Grupos de funções do tipo DADOS:

Arquivo Lógico Interno (ALI) Arquivo de Interface Externa (AIE)

� Grupos de funções tipo TRANSAÇÕES:

Entrada Externa (EE) Saída Externa (SE) Consulta Externa (CE)

� Etapa IV - Cálculo do fator de ajuste

(Fatores relacionados com características da aplicação que afetam o tamanho funcional de um sistema).

� O fator de ajuste é responsável pela correção das distorções da etapa anterior.

� A metodologia de pontos de função considera que outros fatores afetam o tamanho funcional de um sistema.

Estes fatores estão relacionados com características da aplicação: 1. Comunicação de dados 8.Atualização on-line 2. Funções distribuídas 9. Processamento complexo 3. Performance 10. Reusabilidade



4. Configuração do equipamento 11. Facilidade de implantação 5. Volume de transações 12. Facilidade operacional 6. Entrada de dados on-line 13.Múltiplos locais 7. Interface com o usuário 14. Facilidade de mudanças

� Processo de Cálculo: � Avaliar o impacto de cada uma das 14 características em relação

ao sistema que está sendo avaliado, atribuindo pontuação de 0 a 5 para cada característica.

� Calcular o nível de influência geral a partir da soma dos pontos

obtidos em cada uma das 14 características. � Aplica-se a seguinte fórmula:

Fator de Ajuste = (NI * 0,01) + 0,65 � Atualmente o fator de ajuste não tem sido muito utilizado,

pois grande parte das características não se aplica a sistemas em plataformas web ou distribuídas.

� Etapa V - Contagem de pontos de função ajustados

� Correção das possíveis distorções acometidas durante o cálculo dos pontos de função não ajustados

� Trata-se do processo que realiza a correção das possíveis distorções acometidas durante o cálculo dos pontos de função não- ajustados, aproximando as medidas à situação real com base no fator de ajuste.

� Aplica-se a seguinte fórmula: PF = (PF não-ajustado) * (Fator de ajuste) O cálculo de Pontos de Função ajustados também não tem sido muito usado, pelos motivos relacionados ao fator de ajuste.

Cálculo dos Pontos de Função

• Cada tipo de função (ALI, entrada, saída etc.) é classificada de

acordo com sua complexidade: Simples; Média; Alta/Complexa. • Cada complexidade funcional recebe uma pontuação.

Rumo às questões!!



LISTA DE QUESTÕES COMENTADAS NESTA AULA

1. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) No que tange aos paradigmas da Orientação a Objetos (OO), um princípio está diretamente relacionado às operações realizadas por um objeto e ao modo como as operações são executadas, constituindo uma forma de restringir o acesso ao comportamento interno de um objeto. Nesse processo, um objeto que precise da colaboração de outro para realizar alguma tarefa deve enviar uma mensagem a este último. Além disso, separa os aspectos externos de um objeto dos detalhes internos da implementação. Considerando esse contexto, observe a figura abaixo.

O princípio da OO é conhecido por:

A) Compartilhamento

B) Acoplamento

C) Herança

D) Polimorfismo

E) Encapsulamento

Comentários

Encapsular é colocar em uma cápsula. Por mais estranho que pareça, pense que você poderia colocar todos os itens desejados em uma cápsula (como em um remédio) e proteger os componentes internos da ação externa.

Em Orientação a Objetos é bem semelhante. A ideia de encapsular é criar uma proteção para os itens do objeto de forma que somente por meio das interfaces criadas possa ocorrer o acesso às estruturas internas. Isto cria uma proteção para os itens do objeto, que passam a ter o acesso controlado por meio da interface.

O objetivo é separar os aspectos externos (o que faz) dos aspectos internos (como faz):

• Aspectos externos = interface, contrato;

• Aspectos internos = implementação.

O encapsulamento pode ser visto como um complemento da abstração:

• A abstração foca o comportamento observável de um objeto.



• Encapsulamento enfoca a implementação que origina este comportamento.

Além disso, ele – o encapsulamento – promove uma maior estabilidade, uma vez que clientes do objeto só conhecem sua interface e que podemos alterar a implementação de uma operação sem afetar o restante do sistema.

Gabarito: letra E.

2. (CESPE/BANCO DA AMAZÔNIA/Técnico Científico — Área: Tecnologia da Informação — ANÁLISE DE SISTEMAS/2010) Objetos têm identidade própria. Isso garante que, mesmo tendo os mesmos valores de variáveis e pertencendo à mesma classe, dois objetos sejam considerados diferentes.

Comentários

Na orientação a objetos, o conceito de identidade define que um objeto é uma instância única de uma classe, ocupando uma posição de memória específica. Então, podemos ter dois objetos não-idênticos (ocupam posições de memória distintas), mas iguais (são da mesma classe e possuem os mesmos valores para os atributos).

Além disso, cada objeto ao ser criado, aloca espaço de memória para si e possui seus dados armazenados em estrutura própria. Não há confusão entre os objetos, especialmente quanto à identidade. Para simplificar o entendimento, podemos pensar em cada objeto como uma variável estruturada contendo os atributos.

Gabarito: item correto.

3. (CESPE/2010/TRE-MT/Técnico Judiciário/Programação de Sistemas) A estrutura interna de um objeto possui dois componentes básicos: atributos, que descrevem o estado do objeto; e métodos, que são responsáveis pela comunicação entre objetos.

Comentários

Em orientação a objeto, um método é uma subrotina que é executada por um objeto ao receber uma mensagem. Os métodos determinam o comportamento dos objetos de uma classe e são análogos à funções ou procedimentos da programação estruturada. A comunicação entre os objetos é realizada por mensagens que um objeto envia a outro.

Gabarito: item errado.

4. (ESAF/SEFAZ-CE/2007) A representação de classes em diagramas UML contempla os seguintes tipos básicos de informação:

a) o nome da instância da classe e os seus objetos.



b) o nome da classe, os seus atributos e os seus métodos.

c) o nome da instância da classe e os seus relacionamentos.

d) o nome da classe, os seus atributos e suas exceções.

e) o nome da classe e suas visibilidades.

Comentários

A UML (Unified Modeling Language - Linguagem Unificada para Modelagem) normalmente é definida como uma linguagem de modelagem e não um método propriamente dito. A UML apresenta uma série de diagramas para a modelagem de sistemas orientados a objetos.

De todos os diagramas da UML, é o diagrama de classes o mais comumente utilizado pelas empresas. Esse diagrama, de forma simplificada, descreve os “tipos” de objetos do software e os vários tipos de relacionamentos estáticos que existem entre eles. Uma proposta de processo de desenvolvimento que pode ser utilizada em conjunto é o RUP (Rational Unified Process), definido por Booch, Jacobson e Rumbaugh.

Objetos

• Representam elementos do mundo real.

• É uma abstração de conjunto de coisas do mundo real.

• Possuem:

Atributos (estado)

Operações (comportamento).

• O único acesso aos dados desse objeto é através de suas operações.

Classes

• Permitem que sejam representados no mundo computacional elementos do mundo real, ou seja, do problema para o qual o software está sendo desenvolvido.

• Elas permitem descrever um conjunto de objetos que compartilhem os mesmos atributos, operações, relacionamentos e semântica, e representam o principal bloco de construção de um software orientado a objetos.

• Representam os tipos de objetos existentes no modelo, e são descritas a partir de seus atributos, métodos e restrições.



A figura seguinte apresenta a simbologia para uma CLASSE chamada ContaBancaria, utilizando a UML.

Figura. Classe ContaBancaria

Com as classes definidas, precisam-se especificar quais são seus ATRIBUTOS (propriedades que caracterizam um objeto). Por exemplo, uma entidade conta bancária possui como atributos o número e o saldo. É bastante simples identificar os atributos de cada classe, basta identificar as características que descrevam sua classe no domínio do problema em questão. Cabe destacar que os atributos identificados devem estar alinhados com as necessidades do usuário para o problema.

A figura seguinte apresenta a classe ContaBancaria com alguns de seus atributos.

Figura. Classe ContaBancaria com alguns atributos

Identificadas as classes e seus atributos, o próximo passo é a identificação das OPERAÇÕES de cada classe, também chamadas de métodos ou serviços.

Fazendo um paralelo com objetos do mundo real, operações são ações que o objeto é capaz de efetuar. Dessa forma, ao procurar por operações, devem-se identificar ações que o objeto de uma classe é responsável por desempenhar dentro do escopo do sistema que será desenvolvido.

A figura seguinte apresenta algumas operações da classe ContaBancaria. Ao contrário dos atributos, normalmente operações são públicas, permitindo sua utilização por outras classes e objetos.

Figura. Classe ContaBancaria com seus atributos e operações

Finalizando, a UML (Unified Modeling Language - Linguagem Unificada para



Modelagem) nos permite representar graficamente as classes, conforme nos mostrou a figura anterior, dando ênfase às partes mais importantes de uma abstração: seu nome, atributos e operações.

Gabarito: letra B.

5. (CESPE/2009/CEHAP PB/Analista de Sistemas) O projeto orientado a objetos encapsula atributos e serviços ou operações (comportamentos) em objetos. Os objetos comunicam-se entre si por meio de associações e os relacionamentos entre classes se dão por meio de interfaces.

Comentários

Os objetos comunicam-se por meio de mensagens (interface) e os relacionamentos acontecem por meio de associações.

Gabarito: item errado.

6. (ESAF/2008/AFC-STN/INFRAESTRUTURA DE TI) A habilidade para uso de uma mesma mensagem para invocar comportamentos distintos de um determinado objeto é denominada

a) Interface.

b) Polimorfismo.

c) Herança.

d) Encapsulamento.

e) Abstração.

Comentários

Item a. Coleção de métodos que indica que uma classe possui algum comportamento além do que herda de suas superclasses. Os métodos incluídos em uma interface não definem esse comportamento; essa tarefa é definida nas classes que implementam a interface. ITEM FALSO.

Item b. Permite que referências de tipos de classes mais abstratas representem o comportamento das classes concretas que referenciam. Assim, é possível tratar vários tipos de maneira homogênea (através da interface do tipo mais abstrato). O termo polimorfismo é originário do grego e significa "muitas formas" (poli = muitas, morphos = formas). ITEM VERDADEIRO.

Item c. É o mecanismo pelo qual uma classe (sub-classe) pode estender outra classe (super-classe), aproveitando seus comportamentos (métodos) e variáveis possíveis (atributos). Um exemplo: Mamífero é super-classe de Humano. Logo, um Humano é um mamífero. Há herança múltipla quando uma sub-classe possui mais de uma super-classe. ITEM FALSO.

Item d. Consiste na separação de aspectos internos e externos de um objeto. Este mecanismo é utilizado amplamente para impedir o acesso direto ao



estado de um objeto (seus atributos), disponibilizando externamente apenas os métodos que alteram estes estados. Exemplo: Não é necessário conhecer os detalhes dos circuitos de um telefone para utilizá-lo. A carcaça do telefone encapsula esses detalhes, provendo uma interface mais amigável (os botões, o monofone e os sinais de tom). ITEM FALSO.

e) É a habilidade de concentrar nos aspectos essenciais de um contexto qualquer, ignorando características menos importantes ou acidentais. Em modelagem orientada a objetos, uma classe é uma abstração de entidades existentes no domínio do sistema de software. ITEM FALSO.

Gabarito: letra B.

7. (CESPE - 2009 - ANAC - Técnico Administrativo - Informática) A técnica conhecida como refactoring é constantemente aplicada no desenvolvimento baseado no método ágil extreme programming.

Comentários

"Melhorar o projeto depois que foi escrito" é uma premissa do XP.

“É o processo de mudar um sistema de software de tal forma que não se altera o comportamento externo do código, mas melhora sua estrutura interna. É um meio disciplinado de limpar o código e que reduz as possibilidades de introduzir erros. Em essência quando você refina o código, você melhora o projeto depois que este foi escrito”.


8. (FUNRIO/Analista – Área S4/MPOG/2009) Na terminologia da UML, a participação é uma característica importante de uma associação, relacionada à necessidade, ou não, da existência dessa associação entre objetos. Por exemplo, numa associação com conectividade “um para muitos” entre as classes Departamento e Empregado, em que a multiplicidade do lado de Departamento é 1 e do lado de Empregado é 1..*, a participação dos objetos de ambas as classes na associação é

A) opcional.

B)obrigatória.

C) total.

D) parcial.

E) completa.

Comentários

A participação dos objetos de ambas as classes na associação é obrigatória porque o valor mínimo da multiplicidade é 1 em ambos os lados, e deve ser lembrado que a participação é uma característica da associação que está



relacionada com a obrigatoriedade ou não da existência da associação entre todos os objetos das duas classes envolvidas nela.

Gabarito: letra B.

9. (FUNRIO/Analista – Área S4/MPOG/2009) Na modelagem de classes da UML, que tipo de associação entre objetos das classes “pedidos” e “itens de pedido” é identificado na sentença “pedidos são formados por itens de pedido”?

A) Generalização.

B) Especialização.

C) Restrição.

D) Composição.

E) Classificação.

Comentários

Como a composição é um tipo de relacionamento que expressa a ação de fazer parte de algo, quando se fala que pedidos são formados por itens de pedido, este tipo de relacionamento seria o que expressaria melhor o que esta frase exprime.

Gabarito: letra D.

10. (FUNRIO/Analista – Área S4/MPOG/2009) Suponha um diagrama de casos de uso de um sistema de caixa bancário eletrônico, em que os casos de uso “Obter extrato”, “Realizar saque” e “Realizar transferência” têm uma sequência de interações comum para validar a senha do cliente, representada pelo caso de uso “Fornecer identificação”. Qual o tipo de relacionamento dos três primeiros casos de uso com o caso de uso “Fornecer identificação”?

A) Extensão.

B) Agregação.

C) Distribuição.

D) Colaboração.

E) Inclusão.

Comentários

A resposta correta seria inclusão, porque o caso de uso "Fornecer identificação" inclui o comportamento de validar a senha do cliente no caso de uso “Realizar transferência”, sendo assim podemos dizer que “Realizar transferência” usa o caso de uso "Fornecer identificação".

Gabarito: letra E.



11. (ESAF/2005/UML) O modo para descrever os vários aspectos de modelagem ela UML é por meio do uso da notação definida pelos seus vários tipos de diagramas. Segundo as características desses diagramas, é correto afirmar que um diagrama de classe

a) mostra a interação de um caso de uso organizada em torno de objetos e

classes e seus vínculos mútuos, evidenciando a sequência de mensagens.

b) denota a estrutura estática de um sistema.

c) descreve a funcionalidade do sistema.

d) descreve a interação de sequência de tempo dos objetos e classes percebida por atores externos.

e) mostra as sequências de estados que uma classe e objetos assumem em sua vida em resposta a estímulos recebidos, juntamente com suas respostas e ações.

Comentários

Item a. O Diagrama de Classe mostra as diferentes classes que fazem um sistema e como elas se relacionam. Os diagramas de classe são chamados diagramas “estáticos” porque mostram as classes, com seus métodos e atributos bem como os relacionamentos estáticos entre elas: quais classes “conhecem” quais classes ou quais classes “são parte” de outras classes, mas não mostram a troca de mensagens entre elas. ITEM FALSO.

Item b. Como foi mencionada na letra anterior, os Diagramas de Classe são chamados diagramas “estáticos” porque mostram as classes, com seus métodos e atributos bem como os relacionamentos estáticos entre elas. ITEM VERDADEIRO.

Item c. O diagrama de caso de uso descreve a funcionalidade proposta para um novo sistema, que será projetado, ou seja, não está relacionado com o diagrama de classes. ITEM FALSO.

Item d. A interação de sequência de tempo dos objetos e classes está relacionada ao diagrama de sequência. É representando pela sequência de processos (mais especificamente, de mensagens passadas entre objetos). O diagrama de sequência descreve a maneira como os grupos de objetos colaboram em algum comportamento ao longo do tempo. ITEM FALSO.

Item e. O diagrama de estados mostra como um único objeto se comporta através de muitos casos de uso; mostra sequências de estados que um objeto ou uma interação assume em sua vida em resposta a eventos, juntamente com suas respostas e ações; é um complemento de uma classe relacionando os possíveis estados que objetos da classe podem ter e quais eventos podem causar a mudança de estado (transição). Este então não está relacionado ao diagrama de classes. ITEM FALSO.

Gabarito: letra B.



12. (FUNRIO/Analista de Sistemas/FURB/2010) Com base no Diagrama de Classe do Anexo II, indique a alternativa correta.

A) Os atributos da Classe A podem ser alterado indistintamente por qualquer outra classe diretamente.

B) A classe A possui um método que pode ser usado por outros métodos de qualquer classe.

C) Todos os métodos da Classe A podem ser usados pelas suas classes derivadas.

D) O mecanismo de mensagem deverá ser usado por outra classe para alteração de pelo menos 1 atributo da classe A.

E) Os atributos da Classe A não podem ser herdados.

Comentários

Uma subclasse (ou classe derivada) é uma classe que herda comportamentos de outra classe, podendo sobrecarregar funcionalidades e adicionar novas a uma classe base (ou classe pai), construtores e destrutores não são herdados, e somente métodos e atributos públicos e protegidos são herdados. Métodos públicos e protegidos podem ser visíveis por outras classes.

Gabarito: letra C.

13. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) Um modelo é uma abstração de algo com a finalidade de entendê-lo antes de construí-lo. Todo sistema desenvolvido deve ser modelado e, nesse sentido, existem pontos de vista distintos, porém relacionados, cada qual capturando aspectos importantes e necessários para uma descrição completa. Enquanto o modelo de interações representa a colaboração de objetos individuais, os aspectos de “interações” de um sistema representam os aspectos estáticos, estruturais de “dados” e também podem representar os aspectos temporais e comportamentais, de “controle” desse mesmo sistema. Esses dois últimos são denominados, respectivamente, modelos de:



A) Classes e Estados

B) Dados e Controle

C) Eventos e Estados

D) Dados e Estados

E) Classes e Controle

Comentários

Os dois últimos modelos “dados” e “controle” correspondem aos modelos de Classes e Estados, letra A.

Classificação significa que os objetos com a mesma estrutura de dados (chamados atributos) e o mesmo comportamento (chamados operações ou métodos) são agrupados em uma classe. Classe é uma abstração que descreve propriedades importantes para uma aplicação e ignora o restante. O objetivo de um diagrama de classes é descrever os vários tipos de objetos no sistema e o relacionamento entre eles.

Um diagrama de classes pode oferecer três perspectivas, cada uma para um tipo de observador diferente. São elas:

• Conceitual

o Representa os conceitos do domínio em estudo.

o Perspectiva destinada ao cliente.

• Especificação

o Tem foco nas principais interfaces da arquitetura, nos principais métodos, e não como eles irão ser implementados.

o Perspectiva destinada as pessoas que não precisam saber detalhes de desenvolvimento, tais como gerentes de projeto.

• Implementação - a mais utilizada de todas

o Aborda vários detalhes de implementação, tais como navegabilidade, tipo dos atributos, etc.

o Perspectiva destinada ao time de desenvolvimento.

Um diagrama de classes contém:

* Entidades

* Relacionamentos

Os Diagramas de Máquinas de Estados, ou simplesmente Diagramas de Estados, descrevem o comportamento dinâmico do sistema, representando os estados que um objeto passa durante a execução do sistema e como ele muda de estado em respostas aos eventos. Cada diagrama representa uma classe única.

Em um diagrama de estado, um objeto possui um comportamento e um estado. O estado de um objeto depende da atividade na qual ele está



processando. Um diagrama de estado mostra os possíveis estados de um objeto e as transações responsáveis pelas suas mudanças de estado.

Gabarito: letra A.

14. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) A Engenharia de Requisitos fornece o mecanismo apropriado para entender o que o cliente deseja, analisando as necessidades, avaliando a exequibilidade, negociando uma condição razoável, especificando a solução de forma clara, validando a especificação e gerindo os requisitos à medida que eles são transformados em um sistema operacional. Considerando esse contexto, observe a figura abaixo, utilizada no levantamento de requisitos.

Essa figura é conhecida por Diagrama:

A) Funcional

B) De Classes

C) De Contexto

D) De Atividades



E) Comportamental

Comentários

O objetivo do diagrama de atividades é mostrar o fluxo de atividades em um único processo. O diagrama mostra como uma atividade depende uma da outra.

Um diagrama de atividade pode ser regiões denominadas swimlanes. Estas regiões estão associadas a um objeto do modelo. Desta forma, dentro de cada região, encontram-se as atividades relativas ao objeto da região. As atividades são conectadas através de arcos (transições), que mostram as dependências entre elas.

Gabarito: letra D.

15. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) A UML é uma linguagem de modelagem visual, podendo ser definida como um conjunto de notações e semântica correspondente para representar visualmente uma ou mais perspectivas de um sistema. Dentre os diagramas da UML, um diagrama foca os requisitos funcionais de um sistema, forçando os



desenvolvedores a moldarem o sistema de acordo com o usuário, e não o usuário de acordo com o sistema, representando as especificações de uma sequência de interações entre um sistema e os agentes externos que utilizam esse sistema, por meio dos atores e relacionamentos entre eles. Esse diagrama é denominado:

A) Casos de uso

B) Casos de negócios

C) Processos e funções

D) Entidades e relacionamentos

E) Processos e relacionamentos

Comentários

O diagrama que foca os requisitos funcionais de um sistema é o diagrama de casos de uso.

Os casos de uso descrevem funcionalidades do sistema percebidas por atores externos. Um ator é uma pessoa (ou dispositivo, ou outro sistema) que interage com o sistema.

Gabarito: letra A.

16. (ESAF/2008/AFC/STN/ TI – Desenvolvimento de Sistemas) Em UML (Unified Modeling Language), o diagrama cujo foco é a organização estrutural de objetos que enviam e recebem mensagens, exibindo assim, tais objetos e as ligações entre eles, bem como as respectivas mensagens, é o diagrama de

a) componentes.

b) colaboração.

c) objetos.

d) atividades.

e) caso de uso.



Comentários

Item a. Ilustra como as classes deverão se encontrar organizadas através da noção de componentes de trabalho. Por exemplo, pode-se explicitar, para cada componente, qual das classes que ele representa. Item FALSO.

Item b. Exibe uma interação, consistindo de um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre eles. Item VERDADEIRO.

Item c. É uma variação do diagrama de classes e utiliza quase a mesma notação. A diferença é que o diagrama de objetos mostra os objetos que foram instanciados das classes. O diagrama de objetos é como se fosse o perfil do sistema em um certo momento de sua execução. Item FALSO.

Item d. Representa os fluxos conduzidos por processamentos. É essencialmente um gráfico de fluxo, mostrando o fluxo de controle de uma atividade para outra. Isso envolve a modelagem das etapas sequenciais em um processo computacional. Item FALSO.

Item e. Descreve a funcionalidade proposta para um novo sistema, que será projetado. Representa uma unidade discreta da interação entre um usuário (humano ou máquina) e o sistema. São tipicamente relacionados a "atores". Um ator é um humano ou entidade máquina que interage com o sistema para executar uma determinada tarefa. Item FALSO.

Gabarito: letra B.

17. (ESAF/2008/AFC/STN/TI/Infraestrutura) O diagrama UML que apresenta objetos e suas ligações mútuas, evidenciando a sequência das mensagens trocadas por meio de números de sequência, é o

a) Diagrama de sequência.

b) Diagrama de estado.

c) Diagrama de colaboração.

d) Diagrama de caso de uso.

e) Diagrama de atividade.

Comentários

Item a. O Diagrama de Sequência representa a sequência de processos (mais especificamente, de mensagens passadas entre objetos) num programa de computador. Como um projeto pode ter uma grande quantidade de métodos em classes diferentes, pode ser difícil determinar a sequência global do comportamento. O diagrama de sequência representa essa informação de uma forma simples e lógica. Este descreve a maneira como os grupos de objetos colaboram em algum comportamento ao longo do tempo. Ele registra o comportamento de um único caso de uso e exibe os objetos e as mensagens passadas entre esses objetos no caso de uso. Item FALSO.



Item b. O Diagrama de Estado mostra o ciclo de vida de um objeto os eventos pelos quais ele passa, as suas transições e os estados em que ele está entre estes eventos. Um estado de um objeto é um conjunto de circunstâncias ou atributos que caracterizam o objeto em determinado momento. Item FALSO.

Item c. O Diagrama de Colaboração exibe uma interação, consistindo de um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre eles. O Diagrama de colaboração mostra, de maneira semelhante ao diagrama de sequência, a colaboração dinâmica entre os objetos. Se a ênfase do diagrama for o contexto do sistema, o diagrama de colaboração é o utilizado. Item VERDADEIRO.

Item d. Tem o objetivo de auxiliar a comunicação entre os analistas e o cliente. Descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. O cliente deve ver no diagrama de casos de uso as principais funcionalidades de seu sistema. Item FALSO.

Item e. Uma atividade é o estado de estar fazendo algo: tanto um processo de mundo real, tal como datilografar uma carta, ou a execução de uma rotina de software, tal como um método em uma classe. Este descreve a sequência de atividades, com suporte para comportamento condicional e paralelo. Um Diagrama de Atividades é uma variante de um diagrama de estados no qual a maioria, se não todos, dos estados é estado de atividade. Portanto, muito da terminologia segue a mesma terminologia de estados. Item FALSO.

Gabarito: letra C.

18. (ESAF/2008/AFC/STN/TI/Infraestrutura) Considere o seguinte contexto: “Um cliente pode comprar vários livros”. Em um diagrama de classes, este é um exemplo de relacionamento do tipo

a) Agregação.

b) Generalização.

c) Especialização.

d) Associação.

e) Dependência.

Comentários

Item a. Item FALSO. Agregação é uma forma especializada de associação na qual um todo é relacionado com suas partes. Também conhecida como relação de conteúdo. É representada como uma linha de associação com um diamante junto à Classe agregadora. A multiplicidade é representada da mesma maneira que nas associações.

Complementando, a agregação é um caso particular da associação. A agregação indica que uma das classes do relacionamento é uma parte, ou está contida em outra classe. As palavras chaves usadas para identificar uma agregação são: “consiste em”, “contém”, “é parte de”.



Comentários

Item a. Adornos são detalhes da especificação adicionados às extremidades das linhas que representam os relacionamentos, usados na notação gráfica. Item FALSO.

Item b. Permite estender o vocabulário da linguagem, criando novos elementos de modelagem. O estereótipo estende a semântica mas não a estrutura do elemento. Podem-se criar novos ícones para representar esses elementos numa forma gráfica individualizada. Item VERDADEIRO.

Item c. Uma restrição estende a semântica de um elemento UML, permitindo a definição de novas regras ou modificação de regras existentes. Item FALSO.

Item d. A UML não é só uma linguagem gráfica, por trás de toda parte gráfica há uma especificação que define a sintaxe e semântica de um elemento. A especificação pode ser construída de forma incremental e estará sempre por trás, valendo, para qualquer tipo de exibição utilizado. As especificações UML proveem um pano de fundo que envolve todas as partes de um modelo. Item FALSO.

Item e. São relacionamentos de utilização no qual uma mudança na especificação de um elemento pode alterar a especificação do elemento dependente. A dependência entre classes indica que os objetos de uma classe usam serviços dos objetos de outra classe. Item FALSO.

Gabarito: letra B.

20. (FUNRIO/Analista – Área S4/MPOG/2009) Os modelos ágeis de desenvolvimento de software foram projetados para atender a quatro tópicos-chave. Qual das alternativas NÃO É um tópico-chave?

A) Importância de equipes auto-organizadas que têm controle sobre o trabalho que executam.

B) Automatização da documentação dos sistemas em bases de conhecimento.

C) Comunicação e colaboração entre os membros da equipe e entre os profissionais e seus clientes.

D) Reconhecimento de que modificações representam uma oportunidade.

E) Ênfase na entrega rápida de softwares que satisfaçam ao cliente.

Comentários

Ágil é uma nova forma de gestão e desenvolvimento de Software que usa uma abordagem de planejamento e execução iterativa e incremental voltado para processos empíricos que divide o problema em produtos menores e que visa entregar software funcionando regularmente, visa a aproximação e maior colaboração do time de desenvolvimento com os experts de negócios, comunicação face-to-face, redução dos riscos associados as incertezas dos projetos, abraçar e responder as mudanças de forma mais rápida e natural e é



claro a satisfação final dos clientes por meio da adoção de práticas de gestão e de engenharia de software com foco nos valores e princípios do Lean e do agile, resumindo, seu principal objetivo é entregar o produto que o cliente realmente deseja e que será útil e com qualidade.

Gabarito: letra B.

Com relação a conceitos gerais de engenharia de software, julgue os itens a seguir.

21. (CESPE/TRT - 10ª REGIÃO (DF e TO) - Analista Judiciário - Tecnologia da Informação/2013) As atividades fundamentais relacionadas ao processo de construção de um software incluem a especificação, o desenvolvimento, a validação e a evolução do software.

Comentários

Um processo de software é um conjunto de atividades e resultados associados que levam à produção de um produto de software.

Nesse contexto, Sommerville (2007, p. 43) destaca as quatro atividades fundamentais do processos de software, comuns a todos eles, que são: especificação de software, projeto e implementação de software, validação de software e evolução do software.

Especificação de Software São definidas as funcionalidades do software e restrições para sua operação.

Projeto e Implementação de Software

O software que atenda à especificação deve ser produzido.

Validação de Software O software deve ser avaliado para garantir que ele faça o que o cliente deseja.

Evolução do Software O software evolui para atender às necessidades de mudança do cliente.

Segundo o autor, essas atividades são organizadas de modo diferente nos diversos processos de desenvolvimento. Como exemplo, no modelo em cascata são organizadas em sequência, ao passo que, no desenvolvimento evolucionário, elas são intercaladas. Como essas atividades serão organizadas dependerá do tipo de software, pessoas e estruturas organizacionais envolvidas.

Com algumas variações de nomes entre os principais autores da área (Pressman e Sommerville), é correto destacar que as quatro atividades básicas do processo de software são: especificação, desenvolvimento, validação e evolução.




22. (CESPE/ 2013 /TRT - 10ª REGIÃO (DF e TO)/Analista Judiciário - Tecnologia da Informação) O ciclo de vida de um software, entre outras características, está relacionado aos estágios de concepção, projeto, criação e implementação.

Comentários

Sommerville (2007, p. 43) destaca as quatro atividades fundamentais do processos de software, comuns a todos eles, que são: especificação de software, projeto e implementação de software, validação de software e evolução do software. Segundo o autor, essas atividades são organizadas de modo diferente nos diversos processos de desenvolvimento.

Pressman (2011) destaca que uma metodologia de processo genérica para Engenharia de Software compreende cinco atividades:

• Comunicação – Antes de iniciar o trabalho, é de vital importância comunicar-se e colaborar com o cliente (e outros interessados, como: executivos, usuários finais, engenheiros de software, o pessoal de suporte, etc.). A intenção aqui é compreender os objetivos das partes interessadas para com o projeto e fazer o levantamento das necessidades que ajudarão a definir as funções e características do software.

• Planejamento – Estabelecimento do plano de projeto de software, que descreve as tarefas técnicas a ser conduzidas, os riscos prováveis, os recursos que serão necessários, os produtos resultantes a ser produzidos e um cronograma de trabalho.

• Modelagem – Criação de modelos representativos do software (para melhor entender as necessidades do software e o projeto que irá atender a essas necessidades).

• Construção – Essa atividade combina geração de código (manual ou automatizada) e testes necessários para revelar erros na codificação.

• Entrega (Implantação) – Entrega do produto ao cliente, que irá avalia-lo e fornecer feedback baseado na avaliação.

Essas cinco atividades metodológicas genéricas podem ser utilizadas para o desenvolvimento de programas pequenos e simples, para a criação de grandes aplicações para a Internet e para a engenharia de grandes e complexos sistemas baseados em computador (Pressman, 2011).

As atividades metodológicas são complementadas pelas atividades de apoio (umbrella activities), como: controle e acompanhamento do projeto, administração de riscos, garantia da qualidade, gerenciamento da configuração de software, dentre outras.

Observe que os 2 autores trabalham com um modelo genérico de processo de software, e não com o ciclo de vida do software. No entanto, conceitualmente falando, o modelo de processo de software não se diferencia do modelo de ciclo de vida, ambos trazem uma descrição, em alto nível, das atividades envolvidas na construção de um software e suas dependências. Ainda, cabe destacar que as sequências de atividades trazidas pelo Pressman e



Sommerville são essencialmente iguais e estão falando do mesmo processo: o desenvolvimento de um software.

Assim, pode-se destacar que o ciclo de vida de um software, entre outras características, estará relacionado aos estágios de concepção, projeto, criação e implementação.


23. (CESPE/TRE-BA/Analista de Sistemas/2010) Com relação à engenharia de software, julgue o item a seguir. Entre os desafios enfrentados pela engenharia de software estão lidar com sistemas legados, atender à crescente diversidade e atender às exigências quanto a prazos de entrega reduzidos.

Comentários

A proposta da Engenharia de software é possibilitar o desenvolvimento adequado do software, frente a inúmeros desafios, como: lidar com sistemas legados (sistemas de software mais velhos que permanecem vital para uma organização), atender à crescente diversidade e atender às exigências quanto a prazos de entrega limitados.


24. (ESAF/MPOG/2008) O processo da engenharia de sistemas possui importantes diferenças em relação ao processo de desenvolvimento de software, principalmente no que se refere às suas fases. Indique a opção que representa as fases do processo da engenharia de sistemas.

a) Comunicação, Planejamento, Modelagem, Construção e Implantação.

b) Análise de requisitos, Projeto do sistema, Projeto do programa, Codificação, Testes de Unidades e de Integração, Teste do sistema, Teste de Aceitação, Operação e Manutenção.

c) Definição de Requisitos, Projeto de sistemas e de software, Implementação e testes de unidades, Integração e testes de sistemas, Operação e manutenção.

d) Análise dos requisitos do sistema, Projeto da arquitetura do sistema, Codificação e testes do sistema, Integração e teste do sistema, Teste de qualificação do sistema, Instalação do sistema e Descontinuação do sistema.

e) Definição de requisitos, Projeto do sistema, Desenvolvimento de subsistemas, Integração do sistema, Instalação do sistema, Evolução do sistema e Desativação do sistema.



Comentários

A engenharia de sistemas é uma atividade de especificação, projeto, implementação, validação, implantação e manutenção de sistemas sociotécnicos.

Os engenheiros de sistema são responsáveis pelos softwares, e não somente esses, mas também o hardware, as interações do sistema com os usuários e seu ambiente. Além disso, serviços que o sistema fornece, restrições de operação, criação e utilização, a fim de atingir seu propósito (SOMMERVILLE, 2007).

Figura. Fonte: (SOMMERVILLE, 2007)

Gabarito: letra E.

25. (CESPE/2013/TRT - 10ª REGIÃO (DF e TO)/Analista Judiciário - Tecnologia da Informação) Com relação a conceitos gerais de engenharia de software, julgue os itens a seguir.

A engenharia de software engloba processos, métodos e ferramentas. Um de seus focos é a produção de software de alta qualidade a custos adequados.

Comentários

• Processo de Software: é um conjunto de atividades, cuja meta é o desenvolvimento ou a evolução do software.

• Métodos de Engenharia de Software: são as abordagens estruturadas para o desenvolvimento de software, que incluem modelos de sistemas, notações, regras, recomendações de projetos e diretrizes de processos.



Comentários

O Modelo em Cascata (Também chamado de clássico, ou linear) sugere uma abordagem sequencial e sistemática para o desenvolvimento de software, aplicando as atividades de maneira linear. Em cada fase desenvolvem-se artefatos (produtos de software) que servem de base para as fases seguintes.

A prototipação consiste em confirmar ou refutar hipóteses. Senta-se com o cliente e realiza um projeto rápido para atender somente a aspectos do software que ficarão visíveis (protótipo).Para tal, o prazo de construção do mesmo deve ser obrigatoriamente curto, o que não possibilita formalismos (“abordagem sequencial e sistemática”), ao contrário do que foi sugerido no enunciado da questão. Gabarito: item errado.

29. (ESAF/STN/Analista de Finanças e Controle/Governança e Gestão em TI/2013) O desenvolvimento ágil de software fundamenta-se no Manifesto Ágil. Segundo ele deve-se valorizar:

a) mudança de respostas em vez do seguimento de um plano.

b) indivíduos e interações em vez de processos e ferramentas.

c) documentação extensiva operacional em vez de software funcional.

d) indivíduos e intenções junto a processos e ferramentas.

e) seguimento de um plano em vez de resposta a mudança.

Comentários

O Manifesto Ágil contém quatro valores fundamentais, que são:

• Os indivíduos e suas interações acima de procedimentos e ferramentas;

• Software funcional acima de documentação abrangente;

• A colaboração dos clientes acima da negociação de contratos;

• A capacidade de resposta a mudanças acima de um plano pré-estabelecido;

Fonte: http://manifestoagil.com.br/

Assim, temos:

Item A. Item errado. Temos aqui a capacidade de resposta às mudanças, ao invés de seguir um plano pré-estabelecido.

Item B. Item correto. Os indivíduos e suas interações acima de procedimentos e ferramentas.

Item C. Item errado. Software funcional acima de documentação abrangente.



Item D. Item errado. Os indivíduos e suas interações acima de procedimentos e ferramentas.

Item E. Item errado. A capacidade de resposta a mudanças acima de um plano pré-estabelecido.

Gabarito: letra B.

30. (FUNRIO/Analista – Área S4/MPOG/2009) Sobre o teste caixa branca de software, é correto afirmar que

A) é baseado em um exame rigoroso do detalhe procedimental.

B) refere-se a testes que são conduzidos na interface do software.

C) examina apenas algum aspecto fundamental do sistema.

D) elimina qualquer possibilidade de incorreção do sistema.

E) é conduzido nas instalação dos usuários finais, sem a presença dos desenvolvedores.

Comentários

O teste caixa branca, comumente chamado de teste estrutural, é uma técnica de teste que analisa o código fonte (no caso de teste de software) ou cada nó de um circuito que pode vir a ser testado (no caso de teste de hardware) o que significa que ele olha os procedimentos.

Gabarito: letra A.

31. (FUNRIO/Analista – Área S4/MPOG/2009) A métrica de pontos de função que mede a funcionalidade entregue por um sistema pode ser usada para

A) verificar o atendimento do sistema aos requisitos do usuário.

B) garantir o cumprimento de metas no cronograma de desenvolvimento.

C) prever o número de componentes e/ou de linhas de código do sistema.

D) selecionar a melhor plataforma de hardware e software básico para o sistema.

E) validar a escolha da linguagem de programação para o desenvolvimento do sistema.

Comentários

Análise de Pontos de Função (APF) é uma técnica de medição das funcionalidades fornecidas por um software do ponto de vista de seus usuários. Ponto de função (PF) é a sua unidade de medida, que tem por objetivo tornar a medição independente da tecnologia utilizada para a construção do software.



Ou seja, a APF busca medir o que o software faz, e não como ele foi construído.

Gabarito: letra C.

32. (FUNRIO/2013/ MPOG - Analista de Tecnologia da Informação ) Na Análise de Pontos de Função, fatores de ajustamento são usados para fornecer uma indicação da complexidade do problema. Tais fatores de ajustamento são baseados em 14 características gerais do sistema como, por exemplo, Comunicação de Dados e Desempenho. Qual das alternativas abaixo NÃO é uma característica geral do sistema usada no cálculo do valor do fator de ajustamento?

a) Entrada de dados online.

b) Reusabilidade.

c) Facilidade operacional.

d) Processamento complexo.

e) Disponibilidade 24x7.

Comentários

As 14 características gerais da aplicação são: 1. Comunicação de dados 8.Atualização on-line 2. Funções distribuídas 9. Processamento complexo 3. Performance 10. Reusabilidade 4. Configuração do equipamento 11. Facilidade de implantação 5. Volume de transações 12. Facilidade operacional 6. Entrada de dados on-line 13.Múltiplos locais 7. Interface com o usuário 14. Facilidade de mudanças Conforme visto, disponibilidade 24x7 é a única que não se encontra na relação.

Gabarito: letra E.

33. (FUNRIO/2013/ MPOG/Analista de Tecnologia da Informação / Engenharia de Software ) No processo unificado de desenvolvimento de software, qual é a fase em que o planejamento do projeto é completado, o domínio do negócio é analisado e os requisitos do sistema são ordenados considerando-se prioridade e risco?

a) Concepção.

b) Elaboração.

c) Construção.



d) Transição.

e) Produção.

Comentários

O Rational Unified Process é um processo de desenvolvimento iterativo e incremental, no qual o software não é implementado em um instante no fim do projeto, mas é, ao contrário, desenvolvido e implementado em partes. A cada iteração deste processo utiliza-se quatro fases, a saber: Concepção, Elaboração, Construção e Transição.

• Durante a Concepção ou Início (Inception), estabelece-se a lógica do domínio da aplicação para o projeto e decide o escopo do projeto. É aqui que se obtém o comprometimento do patrocinador do projeto para seguir adiante. Nesta fase compreende-se o problema da tecnologia empregada por meio da definição dos use cases mais críticos. Define-se aqui o caso de negócio e escopo do projeto.

• Na Elaboração (Elaboration) coleta-se requisitos mais detalhados, faz uma análise e um projeto de alto nível para estabelecer uma arquitetura básica, e cria um plano para a construção do sistema. Deve-se analisar o domínio do problema, estabelecer a arquitetura, desenvolver o plano do projeto e eliminar elementos de alto risco.

• A fase de Construção (Construction) consiste de várias iterações, nas quais cada iteração constrói software de qualidade de produção, testado e integrado, que satisfaz um subconjunto de requisitos de projeto. Cada iteração contém todas as fases usuais do ciclo de vida da análise, do projeto, da implementação e do teste. Desenvolve-se o software e prepara-se o mesmo para a transição para os usuários. Além do código, também são produzidos os casos de teste e a documentação.

• Mesmo com este tipo de processo iterativo, algum trabalho tem que ser deixado para ser feito no fim, na fase de Transição (Transition). Nesta fase são realizados os treinamentos dos usuários e a transição do produto para utilização. Este trabalho pode incluir também testes beta e ajuste de performance.

Gabarito: letra B.

34. (FUNRIO/2013/ MPOG - Analista de Tecnologia da Informação / Engenharia de Software) Geralmente, um caso de uso tem diversas maneiras de ser realizado. Qual é a denominação dada à descrição de uma das maneiras pelas quais o caso de uso pode ser realizado, também chamado de instância de um caso de uso?

a) Panorama.

b) Quadro.



c) Cenário.

d) Protótipo.

e) Iteração.

Comentários

Cenário é a descrição de uma das maneiras pelas quais um caso de uso pode ser realizado. É relacionado à forma como ele pode ser realizado. Um cenário é uma execução específica do caso de uso; pode ser visto como uma instância de um Caso de Uso.

Gabarito: letra C.

35. (FUNRIO/Analista – Área S4/MPOG/2009) No contexto do projeto de software no nível de componente, a medida qualitativa do grau em que as classes são conectadas entre si, que cresce quando as classes e componentes tornam-se mais interdependentes, é denominada

A) acoplamento.

B) coesão.

C) abstração.

D) modularidade.

E) conectividade.

Comentários

O acoplamento é uma medida de quão fortemente uma classe está conectada, possui conhecimento ou depende de outra classe.



Algumas observações:

Coesão Medida da funcionalidade de um módulo; o quanto ele realiza uma tarefa específica. O ideal é que tenhamos uma coesão ALTA!

Medidas de Coesão:

Acoplamento Mede o grau de interdependência entre módulos. O ideal é que tenhamos um acoplamento baixo!

Pressman destaca que “o acoplamento é uma medida da interconexão entre os módulos de uma estrutura de software, depende da complexidade de interface entre módulos”.

Medidas de acoplamento:

Gabarito: letra A.

36. (FCC/Assembleia Legislativa do Estado de São Paulo –Agente Técnico Legislativo – Tecnologia da Informação/2010) São consideradas metodologias ágeis de desenvolvimento de software:

a) XP e UP.

b) SCRUM e DSDM.

c) SCRUM e RUP.

d) DSDM e Cascata.

e) Cascata e PRINCE2.



Comentários

O jeito aqui é eliminarmos o que temos certeza de que não é metodologia ágil, então vamos lá!

O modelo em Cascata (Waterfall), também chamado de Clássico, é o mais tradicional processo de desenvolvimento de software, e então podemos descartar as letras (d) e (e).

O Rational Unified Process (RUP) é um exemplo de modelo de processo de desenvolvimento baseado no Unified Process (Processo Unificado) desenvolvido pela Rational. Então já eliminados RUP e UP (Processo Unificado) que não tem relação com a metodologia ágil, o que excluirá as assertivas (a)e(d).

Por eliminação, chegamos à letra D.

O Scrum é um processo de desenvolvimento ágil de software baseado em grupos de práticas e papeis pré-definidos. Ele é um processo iterativo e incremental para gerenciamento de projetos e desenvolvimento de sistemas, em que cada sprint é uma iteração que segue um ciclo PDCA (Plan, Do, Check, Act) e entrega um incremento de software pronto.

Por fim, o DSDM (Dynamic Systems Development Method - Método de Desenvolvimento de Sistemas Dinâmicos), segundo Pressman (2011, p. 96) é uma abordagem de desenvolvimento de software ágil que “oferece uma metodologia para construir e manter sistemas que atendem restrições de prazo apertado através do uso da prototipagem incremental em u ambiente de projeto controlado.

Gabarito: letra B.

37. (CEPERJ/2010/CEDAE/Analista de Sistemas - Processos) Um paradigma da Engenharia de Software é representado por um método sequencial e sistemático, em que o resultado de uma fase é utilizado como entrada da fase seguinte. Ele inicia no nível de sistemas e avança ao longo da análise, projeto, codificação, teste e manutenção. Esse paradigma é conhecido por método:

A) Espiral

B) Clássico

C) Incremental

D) Estruturado por objetivos

E) Orientado por interatividade

Comentários

O modelo clássico ou cascata, que também é conhecido por abordagem “top-down”, foi proposto por Royce em 1970. Considerado um dos mais importantes modelos, o modelo Clássico é a referência para muitos outros modelos, servindo de base para diversos projetos atuais. Pode-se dizer que a versão



original deste modelo foi melhorada ao longo do tempo e continua sendo muito utilizado hoje em dia.

Gabarito: letra B.

38. (FUNRIO/2013/MPOG/Analista de Tecnologia da Informação) Considere o seguinte problema encontrado em projetos de desenvolvimento de software: “Projetos reais raramente seguem um fluxo sequencial. Apesar de um modelo linear poder acomodar a iteração, ele o faz indiretamente. Como resultado, as modificações podem causar confusão à medida que a equipe de projeto prossegue.” Esse é um dos problemas que são algumas vezes encontrados quando é aplicado o modelo de desenvolvimento

a) em cascata.

b) ágil.

c) espiral.

d) incremental.

e) unificado.

Comentários

O modelo em Cascata sugere uma abordagem sequencial e sistemática para o desenvolvimento de software, aplicando as atividades de maneira



linear. Em cada fase desenvolvem-se artefatos (produtos de software) que servem de base para as fases seguintes.

Como desvantagens desse modelo podemos destacar que:


• dificuldade do cliente em declarar todas as suas necessidades no início do projeto.


Gabarito: letra A.

39. (Consulplan/Pref. Manhuaçu/2010) Em relação aos Projetos de Sistemas de Software, assinale a sequência correta de desenvolvimento de um sistema:

A) Análise, Projeto, Implementação, Testes, Instalação/Implantação

B) Projeto, Análise, Implementação, Instalação/Implantação, Testes

C) Análise, Projeto, Implementação, Instalação/Implantação, Testes

D) Projeto, Implementação, Análise, Instalação/Implantação, Testes

E) Testes, Análise, Projeto, Implementação, Instalação/Implantação

Comentários

De uma maneira geral, as etapas de desenvolvimento de um sistema dividem-se em:

� Levantamento de Requisitos: tem por objetivo propiciar que usuários e desenvolvedores tenham a mesma compreensão do problema a ser resolvido.

� Análise: tem por objetivo construir modelos que determinam qual é o problema para o qual estamos tentando conceber uma solução de software.

� Projeto: estágio no qual o modelo de análise terá de ser adaptado de tal modo que possa servir como base para implementação no ambiente alvo.

� Codificação (implementação): a codificação do sistema é efetivamente executada.

� Teste: consiste na verificação do software.

� Implantação: entrada em produção do sistema.

Gabarito: letra A.

40. (Cesgranrio/Funasa/2009) À luz da Engenharia de Software, o ciclo de vida clássico, também chamado de modelo sequencial linear ou modelo em cascata, é um paradigma aplicável ao desenvolvimento de sistemas de informações que



(A) enfatiza a análise de riscos, que é feita no início do projeto e revisada a cada fase, incluindo um plano de ataque e ações de mitigação dos riscos, aumentando as chances de sucesso do projeto.

(B) prevê uma sequência (ou cascata) de entregas de versões do sistema ao longo do desenvolvimento do mesmo, o que proporciona uma avaliação de progresso baseada em código funcionando, em vez de quantidade de documentação gerada.

(C) exige que todos os requisitos sejam conhecidos e corretamente especificados no início do ciclo de vida, dificultando a acomodação de mudanças que surjam nas fases posteriores.

(D) foi sempre pouco utilizado na prática, pois se apoia em analogias com práticas de engenharia convencional que não se aplicam bem ao desenvolvimento de sistemas de informação.

(E) utiliza a estratégia dividir para conquistar (divide to conquer), prevendo que cada fase do ciclo de vida seja desdobrada em um miniciclo de vida sequencial completo, formando uma cascata de ciclos de vida até o limite adequado para lidar com a complexidade do sistema.

Comentários

O modelo em Cascata (Waterfall), também chamado de Clássico, é o mais tradicional processo de desenvolvimento de software. Este modelo sugere uma abordagem sequencial para o desenvolvimento de software, aplicando as atividades de maneira linear. Exige, portanto, que todos os requisitos sejam conhecidos e corretamente especificados no início do ciclo de vida, dificultando a acomodação de mudanças que surjam nas fases seguintes. Esse modelo possui como vantagem principal a simplicidade para a sua aplicação e gerência. No entanto, algumas desvantagens podem ser observadas:


• dificuldade do cliente em declarar todas as suas necessidades no início do projeto, dificultando a implementação de mudanças que surjam nas fases posteriores;


Gabarito: letra C.

41. (ESAF/CGU/ Analista de Finanças e Controle/Desenvolvimento de Sistemas da Informação/2012) A escolha de um modelo é fortemente dependente das características do projeto. Os principais modelos de ciclo de vida podem ser agrupados em três categorias principais:

a) sequenciais, cascata e evolutivos.

b) sequenciais, incrementais e ágeis.

c) sequenciais, incrementais e evolutivos.



Escolha a opção que preenche corretamente a lacuna acima.

a) análise de riscos

b) planejamento

c) engenharia

d) projeto

e) teste

Comentários

O modelo em espiral foi originalmente proposto por Boehm (BOEHM, 1988), em que a sequência de atividades é substituída pelo processo em espiral. Cada loop na espiral representa uma fase do processo de software. Dessa forma, segundo Sommerville (2007), o loop mais interno pode estar relacionado à viabilidade do sistema; o loop seguinte, à definição de requisitos; o próximo, ao projeto do sistema e assim por diante.

Cada loop na espiral está dividido em quatro setores:

• Definição de objetivos: os objetivos específicos dessa fase do projeto são definidos. As restrições sobre o processo e o produto são identificadas e um plano detalhado de gerenciamento é elaborado. Os riscos de projeto são identificados. Dependendo disso, estratégias alternativas podem ser planejadas.

• Avaliação e redução de riscos. Para cada risco de projeto identificado, uma análise detalhada é realizada. Providências são tomadas para reduzir o risco. Por exemplo, se houver risco de que os requisitos não sejam aprovados, um protótipo do sistema poderá ser desenvolvido.

• Desenvolvimento e validação. Após a avaliação de risco, um modelo de desenvolvimento para o sistema é selecionado.

• Planejamento. O projeto é revisado e uma decisão é tomada para prosseguimento ao próximo loop da espiral. Se a decisão for pelo prosseguimento, serão elaborados planos para a próxima fase do projeto. Abortar um projeto se ele apresentar um alto fator de risco.

A elaboração dos objetivos representa o início do ciclo em espiral, como desempenho e funcionalidade. Os caminhos alternativos para alcançar esses objetivos e as restrições impostas sobre cada um deles são, então, enumerados. Cada alternativa é avaliada em relação a cada objetivo e as fontes de riscos de projeto são identificadas.

O próximo passo é resolver esses riscos por meio de atividades de coleta de informações, tais como análise mais detalhada, prototipação e simulação.

Após a avaliação dos riscos, é realizada uma parte do desenvolvimento, seguida pela atividade de planejamento para a próxima fase do processo (SOMMERVILLE, 2007).



Figura. Modelo espiral representando um ciclo de vida inteiro Fonte: (PRESSMAN, 1997).

Gabarito: letra A.

44. (ESAF/2007/SEFAZ-CE) Analise a descrição a seguir.

O paradigma do ciclo de vida clássico da engenharia de software abrange seis atividades. Na atividade de _____________ são traduzidas as exigências de uma representação do software que podem ser avaliadas quanto à qualidade antes que se inicie a codificação.


a) análise

b) engenharia de sistemas

c) teste e análise de riscos

d) coleta de requisitos

e) projeto

Comentários

Como todo produto industrial, o produto de software tem seu ciclo de vida:

• ele é concebido para tentar atender a uma necessidade;

• é especificado, quando essas necessidades são traduzidas em requisitos viáveis;

• é desenvolvido, transformando-se em um conjunto formado por código e

• outros itens, como modelos, documentos e dados;

• passa por algum procedimento de aceitação e é entregue a um cliente;

• entra em operação, é usado, e sofre atividades de manutenção, quando necessário;



• é retirado de operação ao final de sua vida útil.

O ciclo de vida compreende muitas atividades, que são assunto das diferentes áreas da Engenharia de Software.

A figura seguinte mostra um modelo do ciclo de vida clássico da engenharia de software, que é dividido em seis atividades. São elas:

Figura. Modelo em Cascata proposto por Bezerra.

• Levantamento de Requisitos: tem por objetivo propiciar que usuários e desenvolvedores tenham a mesma compreensão do problema a ser resolvido.

• Análise: tem por objetivo construir modelos que determinam qual é o problema para o qual estamos tentando conceber uma solução de software.

• Projeto: estágio no qual o modelo de análise terá de ser adaptado de tal modo que possa servir como base para implementação no ambiente alvo.

• Codificação (implementação): a codificação do sistema é efetivamente executada.

• Teste: consiste na verificação do software.

• Implantação: entrada em produção do sistema.

Foi mencionado nessa questão que a atividade procurada é realizada antes da atividade de codificação, ou seja, antes da implementação do sistema.

A atividade que procuramos é responsável por descrever COMO o sistema será implementado, através da cobertura completa dos requisitos, traduzindo-os numa especificação (KRUCHTEN, 2003), e a resposta correta é Projeto!

Gabarito: letra E.



45. (Cesgranrio/Petrobrás/Engenharia de Software/2010) O modelo de ciclo de vida em cascata

(A) enfatiza a realização sequencial das atividades do desenvolvimento de um produto de software.

(B) enfatiza a comunicação estreita com o cliente durante o desenvolvimento do produto de software.

(C) envolve a ideia principal de criar um protótipo executável e, por meio de transformações sucessivas, chegar ao sistema completamente implementado.

(D) envolve a análise dos riscos envolvidos no desenvolvimento dos requisitos identificados para produto de software.

(E) recomenda a geração de versões incompletas do sistema, que podem ser passadas para o usuário final, o que permite a retroalimentação do processo de desenvolvimento.

Comentários

O modelo de ciclo de vida em cascata enfatiza a progressão sequencial entre uma fase e a seguinte.

Gabarito: letra A.

46. (Cesgranrio/BNDES/Desenvolvimento/2009) No ciclo de vida em cascata, o custo de correção é menor na fase de

(A) testes.

(B) transição.

(C) implementação.

(D) requisitos.

(E) manutenção.

Comentários

Se eu detectar um erro no início do projeto, ou seja, na fase de requisitos, melhor. Quanto mais tarde eu detectar um problema, pior será.

Gabarito: letra D.

47. (FGV/FIOCRUZ/Tecnologista em Saúde - TI - Sistemas de Informação / Engenharia de Software /2010) A figura seguinte ilustra um modelo de processo, que prescreve um conjunto de elementos de processo como atividades de arcabouço, ações de engenharia de software, tarefas, produtos de trabalho, mecanismos de garantia de qualidade e de controle de modificações para cada projeto.



Esse modelo é conhecido como Modelo:

a) por funções.

b) em cascata.

c) incremental.

d) em pacotes.

e) por módulos.

Comentários

Observe o uso das setas, simbolizando o término de uma fase e início de outra, o que caracteriza uma abordagem sequencial, típica do modelo em cascata. Também temos os nomes das fases do modelo, análise, projeto, codificação, teste e manutenção.

O modelo em cascata ou ciclo de vida clássico segundo (Pressman, pg.32) “[...] requer uma abordagem sistemática, sequencial ao desenvolvimento de software, que se inicia no nível do sistema e avança ao longo da análise, projeto, codificação, teste e manutenção.” A ideia principal do Modelo Cascata é que as diferentes etapas de desenvolvimento seguem uma sequência: a saída da primeira etapa “flui” para a segunda etapa e a saída da segunda etapa “flui” para a terceira e assim por diante. As atividades a executar são agrupadas em tarefas, executadas sequencialmente, de forma que uma tarefa só poderá ter início quando a anterior tiver terminado. Após concluída uma etapa ou fase, deve ser feita uma homologação, a fim de verificar se os documentos gerados condizem com os requisitos do sistema. Sendo necessário, devem ser refeitas as tarefas com problemas. Uma vez aprovada a fase, ela não deve ser alterada, pois implica em alteração na fase seguinte, e consequentemente aumento dos custos.

Gabarito: letra B.

48. (FUMARC/Analista de Sistemas/2004) Este trecho foi extraído do livro GHEZZI, Fundamentals of Software Engineering, pg 371:

“O modelo waterfall teve um importante papel por incorporar a disciplina ao processo de desenvolvimento de software e, dessa forma, superar o desestruturado processo de codificar-e-corrigir. Esse modelo introduziu duas contribuições fundamentais para o processo de software: primeiro que o processo de desenvolvimento de software deve ser submetido à disciplina,



planejamento e gerenciamento, e, segundo, que a implementação de um sistema deve ser adiada até que todos os objetivos estejam bem entendidos.”

Marque a alternativa que representa uma ordem ascendente de etapas de desenvolvimento defendidas pelo modelo waterfall.

a) análise de requerimentos, codificação, integração e testes.

b) codificação, análise de requerimentos, integração e testes.

c) integração e testes, análise de requerimentos, codificação.

d) análise de requerimentos, integração e testes, codificação.

Comentários

O nome das fases pode variar, mas temos uma sequência lógica, e conforme visto a seguir a letra A é a que mais se adequa ao modelo Waterfall.

A figura seguinte, proposta por Eduardo Bezerra, mostra o modelo do ciclo de vida clássico da engenharia de software, que é dividido em seis atividades. São elas:

A figura a seguir apresenta outra possibilidade de esquema deste modelo, apresentada pelo Pressman.

Comunicação

Planejamento

Modelagem

Construção

Implantação




Gabarito: letra A.

49. (CESPE/2008/SERPRO) O modelo em cascata consiste de fases e atividades que devem ser realizadas em sequência, de forma que uma atividade é requisito da outra.

Comentários

O modelo em Cascata (Waterfall), também chamado de Clássico, é o mais tradicional processo de desenvolvimento de software. Este modelo sugere uma abordagem sequencial para o desenvolvimento de software, aplicando as atividades de maneira linear. Em cada fase desenvolvem-se artefatos (produtos de software) que servem de base para as fases seguintes.

� Tendência na progressão sequencial entre uma fase e a seguinte.


50. (Cesgranrio/BR Distribuidora/Infraestrutura/2008) Considere a sequência de atividades e eventos apresentada a seguir.

• Projeto de concepção de um novo software de prateleira

• Projeto de desenvolvimento do novo software

• Projeto de marketing de lançamento do software

• Distribuição do software por dois anos

• Projeto de alteração das funcionalidades do software

• Projeto de marketing do software ampliado para atingir novos segmentos de mercado

Esta sequência de atividades é conhecida como

(A) ciclo de vida do produto.

(B) ciclo de vida de projetos.

(C) ciclo de projetos.

(D) projetos de ciclo de vida.



(E) projetos de produtos.

Comentários

A sequência de atividades e eventos apresentada está relacionada ao ciclo de vida do PRODUTO. No ciclo de vida do projeto seriam mencionadas atividades do PMBOK, a abordagem XP utiliza Scrum para gerenciamento, etc.

Gabarito: letra A.

51. (FUMARC/CEMIG/Analista de TI Junior/2010) Sobre modelos de processo de desenvolvimento de software, assinale a alternativa INCORRETA:

a) O Scrum é um processo de desenvolvimento ágil de software baseado em grupos de práticas e papeis pré-definidos. Ele é um processo iterativo e incremental para gerenciamento de projetos e desenvolvimento de sistemas, onde cada sprint é uma iteração que segue um ciclo PDCA (Plan, Do, Check, Act) e entrega um incremento de software pronto.

b) O design centrado no usuário (UCD) é uma abordagem do processo de desenvolvimento de software baseada no entendimento explícito dos usuários, tarefas, e tem como objetivo principal o casamento entre o modelo conceitual embutido no sistema pelo projetista e o modelo mental do usuário.

c) Programação extrema (XP – extreme programming) é um processo de desenvolvimento ágil baseado em feedback rápido, e simplicidade; com enfoque explícito em tempo, custo e qualidade no desenvolvimento, que são alcançados através de uma definição rígida do escopo das funcionalidades da aplicação.

d) O modelo em espiral é um processo de desenvolvimento de software que intercala etapas de projeto e prototipação, combinando conceitos de desenvolvimento top-down e bottom-up, e permitindo, desta forma, análise de riscos e estimativas do progresso do trabalho mais realistas.

Comentários

Item a. O item está correto. O Scrum é um framework de processo ágil utilizado para gerenciar e controlar o desenvolvimento de um produto de software através de práticas iterativas e incrementais. É composto por um conjunto de boas práticas de gestão que admite ajustes rápidos, acompanhamento e visibilidade constantes e planos realísticos.

• Scrum é um processo bastante leve para gerenciar e controlar projetos de desenvolvimento de software e para a criação de produtos.

Item b. Item correto. O design centrado no usuário (UCD) é uma forma de se trabalhar o desenvolvimento de qualquer produto a partir das



necessidades dos usuários. Ele (UCD) envolve a aplicação de metodologias de usabilidade essenciais ao desenvolvimento de sistemas interativos e produtos. Alguns conceitos:

Donald A. Norman → The Design of Everyday Things

“Princípios de design que – quando seguidos – dão respostas aos usuários tornando o uso dos dispositivos mais fácil”

Albert N. Badre → Shaping Web Usability

“Facilidade de uso, e facilidade de aprendizado”

Jeffrey Rubin → Handbook of Usability Testing

“Um conjunto de quatro fatores reunidos em um dispositivo: 1) capacidade de ser usado com sucesso; 2) facilidade de ser usado; 3) capacidade de o usuário aprender a usar o dispositivo de forma simples e rápida; 4) Provocar satisfação visual ao usuário”

Brian Shackel → Usability—context, framework, definition, design and evaluation

“Capacidade, em termos funcionais humanos, de um sistema ser usado com facilidade e de forma eficiente”.

Jesse James Garrett → The Elements of User Experience

“Pensar em usabilidade é pensar em produtos fáceis de usar”

Kreta Chandler e Karen Hyatt → Customer-centered Design

“Efetividade, eficiência e satisfação com a qual usuários conseguem atingir seus objetivos ao utilizar um dispositivo”

Mark Pearrow → Web Site Usability Handbook

“A ciência de aplicação de metodologias ao design para a criação de dispositivos fáceis de usar, de fácil aprendizado e que sejam úteis com o menor índice de desconforto possível”

Jakob Nielsen → Usability Engineering

“Um conjunto de propriedades de uma interface que reúne os seguintes componentes: 1) Fácil aprendizado; 2) Eficiência; 3) Capacidade de memorização; 4) Baixo índice de erros; 5) Satisfação e prazer ao uso”

Item c. Item errado. A Programação extrema (XP – extreme programming) não prevê a definição rígida do escopo das funcionalidades da aplicação, uma vez que é uma metodologia voltada para projetos cujos requisitos são vagos e mudam com frequência.

Item d. Item correto. A principal inovação do Modelo Espiral é guiar o processo de desenvolvimento gerado a partir de um metamodelo com base em análise de riscos e planejamento que é realizado durante toda a evolução do desenvolvimento.

Gabarito: letra C.



52. (FUMARC/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.

Comentários

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 Modelo em Cascata (Waterfall), também chamado de Clássico, que é o mais tradicional processo de desenvolvimento de software.

Este modelo sugere uma abordagem sequencial para o desenvolvimento de software, aplicando as atividades de maneira linear. Em cada fase desenvolvem-se artefatos (produtos de software) que servem de base para as fases seguintes.

O modelo em Cascata possui como vantagem principal a simplicidade para a sua aplicação e gerência. No entanto, algumas desvantagens podem ser observadas:

• Projetos reais raramente seguem este fluxo sequencial.

• Dificuldade do cliente em declarar todas as suas necessidades no início do projeto.

• Demora em apresentar resultados ao cliente.

Gabarito: letra B.

53. (UEL/POSCOMP/2010) Sobre o Ciclo de Desenvolvimento de Software, é correto afirmar:

I. O desenvolvimento em cascata tem como base a ideia de desenvolver uma implementação inicial, mostrar e discutir tal implementação com o usuário e fazer seu aprimoramento por meio de versões subsequentes, até que um sistema adequado tenha sido desenvolvido.

II. No modelo de processo de desenvolvimento em espiral, cada loop na espiral representa uma fase do processo de software. Este modelo exige a consideração direta dos riscos técnicos em todos os estágios do projeto e, se aplicado adequadamente, deve reduzir os riscos antes que eles se tornem problemáticos.

III. O Rapid Application Development (Desenvolvimento Rápido de Aplicação) é um modelo de processo se software incremental que enfatiza um ciclo de desenvolvimento rápido. Este modelo é uma adaptação de



modelo cascata, no qual o desenvolvimento rápido é conseguido com o uso de uma abordagem de construção baseada em componentes.

IV. O modelo incremental combina elementos do modelo em cascata aplicado de maneira iterativa. Em um processo de desenvolvimento incremental, os clientes identificam (esboçam) as funções a serem fornecidas pelo sistema e a importância das mesmas. Em seguida, é definida uma série de estágios de entrega, com cada estágio fornecendo um subconjunto das funcionalidades do sistema.

Assinale a alternativa correta.

a) Somente as afirmativas I e II estão corretas.

b) Somente as afirmativas I e III estão corretas.

c) Somente as afirmativas III e IV estão corretas.

d) Somente as afirmativas I, II e IV estão corretas.

e) Somente as afirmativas II, III e IV estão corretas.

Comentários

Somente a alternativa I está incorreta, isso porque o modelo em cascata é sequencial, e cada uma das fases integrantes do mesmo é entrada para a próxima, o que significa que não existe uma etapa de implementação inicial e uma conversa com o usuário para aprimorar tal implementação, só na fase de entrega é que o desenvolvedor saberá se fora realizado o que o cliente desejava.

Gabarito: letra E.

54. (Fumarc/Prefeitura de Governador Valadares/Analista de Sistemas/2010) Segundo Larman, o Processo Iterativo organiza o trabalho de um projeto de desenvolvimento de software em quatro fases ou marcos principais. Sobre estas fases, assinale a alternativa INCORRETA:

a) Elaboração —implementação iterativa da arquitetura, resolução dos riscos mais altos, identificação da maioria dos requisitos e escopos, e estimativas mais realistas.

b) Construção — implementação iterativa dos elementos restantes mais fáceis e de baixo risco e preparação para distribuição.

c) Transição — inclui os testes beta e distribuição.

d) Concepção — apresenta uma visão refinada do sistema, casos de negócio, escopo do projeto e estimativas bem definidos.

Comentários

Item a. Item correto. Na Elaboração (Elaboration) coletam-se requisitos mais detalhados, faz uma análise e um projeto de alto nível para estabelecer uma arquitetura básica, e cria um plano para a construção do sistema.



Deve-se analisar o domínio do problema, estabelecer a arquitetura, desenvolver o plano do projeto e eliminar elementos de alto risco.

Na fase de elaboração todos (ou a grande maioria dos requisitos) são levantados em detalhes. Numa primeira iteração um ou dois requisitos, os de maior risco e valor arquitetural, são especificados em detalhes. Estes são implementados e servem como base de avaliação junto ao usuário e desenvolvedores para o planejamento da próxima iteração. Em cada nova iteração na fase de elaboração pode haver um seminário de requisitos, em que requisitos antigos são melhor esclarecidos e novos são detalhados. Ao fim da fase, 90% dos requisitos foram levantados em detalhes, o núcleo do sistema foi implementado com alta qualidade, os principais riscos foram tratados e pode-se então fazer estimativas mais realistas.

Item b. Item correto. A fase de Construção (Construction) consiste de várias iterações, nas quais cada iteração constrói software de qualidade de produção, testado e integrado, que satisfaz um subconjunto de requisitos de projeto. Cada iteração contém todas as fases usuais do ciclo de vida da análise, do projeto, da implementação e do teste. Desenvolve-se o software e prepara-se o mesmo para a transição para os usuários. Além do código, também são produzidos os casos de teste e a documentação.

Item c. Item correto. Mesmo com este tipo de processo iterativo, algum trabalho tem que ser deixado para ser feito no fim, na fase de Transição (Transition). Nesta fase são realizados os treinamentos dos usuários e a transição do produto para utilização. Este trabalho pode incluir também testes beta e ajuste de performance.

Item D. Item errado. O objetivo da fase de concepção é levantar, de forma genérica e pouco precisa, o escopo do projeto. Não deve existir aqui a pretensão de especificar de forma detalhada requisitos, a ideia é ter uma visão inicial do problema, estimar de forma vaga esforço e prazos e determinar se o projeto é viável e merece uma análise mais profunda. Portanto, nesta fase de concepção não temos uma visão refinada do sistema e também ainda as estimativas não estão muito bem definidas. Complementando, durante a Concepção ou Início (Inception), estabelece-se a lógica do domínio da aplicação para o projeto e decide o escopo do projeto. É aqui que se obtém o comprometimento do patrocinador do projeto para seguir adiante. Nesta fase compreende-se o problema da tecnologia empregada por meio da definição dos use cases mais críticos. Define-se aqui o caso de negócio e escopo do projeto.

Gabarito: letra D.

55. (Cesgranrio/BNDES/Desenvolvimento/2008) Que situação favorece a escolha do uso de XP para um projeto de desenvolvimento de software, em oposição à escolha do RUP ou do modelo Cascata?

(A) Equipe do projeto localizada em diferentes cidades e com poucos recursos de colaboração.

(B) Equipe do projeto formada por pessoas com alto grau de competitividade.



(C) Cliente do projeto trabalhando em parceria com a equipe do projeto e sempre disponível para retirar dúvidas.

(D) Requisitos do software com pequena probabilidade de mudanças.

(E) Presença de um processo organizacional que exige a elaboração de vários documentos específicos para cada projeto.

Comentários

Na XP todas as decisões sobre o rumo do projeto devem ser tomadas pelo cliente. Com o cliente sempre presente reforçamos a necessidade de comunicação entre as partes.

Gabarito: letra C.

56. (Cesgranrio/MD/2009) A fase que deve acontecer primeiro no desenvolvimento de sistemas de uma empresa que utiliza o modelo de ciclo de vida em cascata é a de

(A) testes.

(B) análise e projeto.

(C) especificação de requisitos.

(D) implantação.

(E) implementação.

Comentários

Em cada fase do modelo de ciclo de vida em cascata desenvolvem-se artefatos (produtos de software) que servem de base para as fases seguintes.

A figura seguinte, proposta por Eduardo Bezerra, mostra o modelo do ciclo de vida clássico da engenharia de software, que é dividido em seis atividades. São elas:




Dentre as fases apresentadas na questão, conforme visto na explicação acima, é a especificação de requisitos que deve acontecer primeiro no desenvolvimento de sistemas de uma empresa que utiliza o modelo de ciclo de vida em cascata.

Gabarito: letra C.

57. (Cesgranrio/Petrobrás/Processo de Negócio/2010) No Ciclo de Vida Clássico, também chamado de Modelo Sequencial Linear ou Modelo Cascata, é apresentada uma abordagem sistemática composta pelas seguintes atividades:

(A) Análise de Requisitos de Software, Projeto, Geração de Código, Teste e Manutenção.

(B) Modelagem e Engenharia do Sistema/Informação, Análise de Requisitos de Software, Projeto, Geração de Código, Teste e Manutenção.

(C) Modelagem e Engenharia do Sistema/Informação, Projeto, Geração de Código, Teste e Manutenção.

(D) Levantamento de Requisitos de Software, Projeto, Geração de Código e Manutenção e Análise de Requisitos de Software.

(E) Levantamento de Requisitos de Software, Projeto, Geração de Código, Teste Progressivo e Manutenção.

Comentários

Dentre as assertivas, a B é a que destaca as principais atividades do modelo em Cascata. Uma especificação das fases desse modelo pode ser vista na questão anterior.

Gabarito: letra B.

CONSIDERAÇÕES FINAIS

Finalizando, desejo muito sucesso a todos nos estudos e concursos vindouros. Todo o esforço feito nessa fase será devidamente recompensado.

“Se seus sonhos estiverem nas nuvens, não se preocupe, pois eles estão no lugar certo; agora, construa os alicerces!"

Os alicerces para uma excelente prova são: persistência, garra, força de vontade, estudo disciplinado e fé em Deus!!!

Um abraço, Profa Patrícia Quintão



REFERÊNCIAS BIBLIOGRÁFICAS

QUINTÃO, Patrícia Lima. Notas de aula, 2012/2013.

BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML, 2. ed., Rio de Janeiro: Elsevier, 2007.

PRESSMAN, R. S. Engenharia de Software: Uma Abordagem Profissional, 7. ed. Porto Alegre: Editora Mc GrawHill, 2011.

SOMMERVILLE, I., Engenharia de Software, 9. ed., São Paulo: Pearson Addison - Wesley, 2011.

PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prática. 2.ed., São Paulo: Prentice Hall, 2004.




LISTA DAS QUESTÕES APRESENTADAS NA AULA

1. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) No que tange aos paradigmas da Orientação a Objetos (OO), um princípio está diretamente relacionado às operações realizadas por um objeto e ao modo como as operações são executadas, constituindo uma forma de restringir o acesso ao comportamento interno de um objeto. Nesse processo, um objeto que precise da colaboração de outro para realizar alguma tarefa deve enviar uma mensagem a este último. Além disso, separa os aspectos externos de um objeto dos detalhes internos da implementação. Considerando esse contexto, observe a figura abaixo.

O princípio da OO é conhecido por:

A) Compartilhamento

B) Acoplamento

C) Herança

D) Polimorfismo

E) Encapsulamento

2. (CESPE/BANCO DA AMAZÔNIA/Técnico Científico — Área: Tecnologia da Informação — ANÁLISE DE SISTEMAS/2010) Objetos têm identidade própria. Isso garante que, mesmo tendo os mesmos valores de variáveis e pertencendo à mesma classe, dois objetos sejam considerados diferentes.

3. (CESPE/2010/TRE-MT/Técnico Judiciário/Programação de Sistemas) A estrutura interna de um objeto possui dois componentes básicos: atributos, que descrevem o estado do objeto; e métodos, que são responsáveis pela comunicação entre objetos.

4. (ESAF/SEFAZ-CE/2007) A representação de classes em diagramas UML contempla os seguintes tipos básicos de informação:

a) o nome da instância da classe e os seus objetos.

b) o nome da classe, os seus atributos e os seus métodos.

c) o nome da instância da classe e os seus relacionamentos.



d) o nome da classe, os seus atributos e suas exceções.

e) o nome da classe e suas visibilidades.

5. (CESPE/2009/CEHAP PB/Analista de Sistemas) O projeto orientado a objetos encapsula atributos e serviços ou operações (comportamentos) em objetos. Os objetos comunicam-se entre si por meio de associações e os relacionamentos entre classes se dão por meio de interfaces.

6. (ESAF/2008/AFC-STN/INFRAESTRUTURA DE TI) A habilidade para uso de uma mesma mensagem para invocar comportamentos distintos de um determinado objeto é denominada

a) Interface.

b) Polimorfismo.

c) Herança.

d) Encapsulamento.

e) Abstração.

7. (CESPE - 2009 - ANAC - Técnico Administrativo - Informática) A técnica conhecida como refactoring é constantemente aplicada no desenvolvimento baseado no método ágil extreme programming.

8. (FUNRIO/Analista – Área S4/MPOG/2009) Na terminologia da UML, a participação é uma característica importante de uma associação, relacionada à necessidade, ou não, da existência dessa associação entre objetos. Por exemplo, numa associação com conectividade “um para muitos” entre as classes Departamento e Empregado, em que a multiplicidade do lado de Departamento é 1 e do lado de Empregado é 1..*, a participação dos objetos de ambas as classes na associação é

A) opcional.

B)obrigatória.

C) total.

D) parcial.

E) completa.

9. (FUNRIO/Analista – Área S4/MPOG/2009) Na modelagem de classes da UML, que tipo de associação entre objetos das classes “pedidos” e “itens de pedido” é identificado na sentença “pedidos são formados por itens de pedido”?

A) Generalização.

B) Especialização.



C) Restrição.

D) Composição.

E) Classificação.

10. (FUNRIO/Analista – Área S4/MPOG/2009) Suponha um diagramade casos de uso de um sistema de caixa bancário eletrônico, em que os casos de uso “Obter extrato”, “Realizar saque” e “Realizar transferência” têm uma sequência de interações comum para validar a senha do cliente, representada pelo caso de uso “Fornecer identificação”. Qual o tipo de relacionamento dos três primeiros casos de uso com o caso de uso “Fornecer identificação”?

A) Extensão.

B) Agregação.

C) Distribuição.

D) Colaboração.

E) Inclusão.

11. (ESAF/2005/UML) O modo para descrever os vários aspectos demodelagem ela UML é por meio do uso da notação definida pelos seus vários tipos de diagramas. Segundo as características desses diagramas, é correto afirmar que um diagrama de classe

a) mostra a interação de um caso de uso organizada em torno de objetos e

classes e seus vínculos mútuos, evidenciando a sequência de mensagens.

b) denota a estrutura estática de um sistema.

c) descreve a funcionalidade do sistema.

d) descreve a interação de sequência de tempo dos objetos e classespercebida por atores externos.

e) mostra as sequências de estados que uma classe e objetos assumem emsua vida em resposta a estímulos recebidos, juntamente com suas respostas e ações.

12. (FUNRIO/Analista de Sistemas/FURB/2010) Com base noDiagrama de Classe do Anexo II, indique a alternativa correta.




A) Os atributos da Classe A podem ser alterado indistintamente por qualquer outra classe diretamente.

B) A classe A possui um método que pode ser usado por outros métodos de qualquer classe.

C) Todos os métodos da Classe A podem ser usados pelas suas classes derivadas.

D) O mecanismo de mensagem deverá ser usado por outra classe para alteração de pelo menos 1 atributo da classe A.

E) Os atributos da Classe A não podem ser herdados.

13. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) Um modelo é uma abstração de algo com a finalidade de entendê-lo antes de construí-lo. Todo sistema desenvolvido deve ser modelado e, nesse sentido, existem pontos de vista distintos, porém relacionados, cada qual capturando aspectos importantes e necessários para uma descrição completa. Enquanto o modelo de interações representa a colaboração de objetos individuais, os aspectos de “interações” de um sistema representam os aspectos estáticos, estruturais de “dados” e também podem representar os aspectos temporais e comportamentais, de “controle” desse mesmo sistema. Esses dois últimos são denominados, respectivamente, modelos de:

A) Classes e Estados

B) Dados e Controle

C) Eventos e Estados

D) Dados e Estados

E) Classes e Controle

14. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) A Engenharia de Requisitos fornece o mecanismo apropriado para entender o que o cliente deseja, analisando as necessidades, avaliando a exequibilidade, negociando uma condição razoável, especificando a solução de forma clara,




validando a especificação e gerindo os requisitos à medida que eles são transformados em um sistema operacional. Considerando esse contexto, observe a figura abaixo, utilizada no levantamento de requisitos.

Essa figura é conhecida por Diagrama:

A) Funcional

B) De Classes

C) De Contexto

D) De Atividades

E) Comportamental

15. (CEPERJ/2010/IPEM-RJ/Analista de Sistemas) A UML é uma linguagem de modelagem visual, podendo ser definida como um conjunto de notações e semântica correspondente para representar visualmente uma ou mais perspectivas de um sistema. Dentre os diagramas da UML, um diagrama foca os requisitos funcionais de um sistema, forçando os desenvolvedores a moldarem o sistema de acordo com o usuário, e não o



usuário de acordo com o sistema, representando as especificações de uma sequência de interações entre um sistema e os agentes externos que utilizam esse sistema, por meio dos atores e relacionamentos entre eles. Esse diagrama é denominado:

A) Casos de uso

B) Casos de negócios

C) Processos e funções

D) Entidades e relacionamentos

E) Processos e relacionamentos

16. (ESAF/2008/AFC/STN/ TI – Desenvolvimento de Sistemas) Em UML (Unified Modeling Language), o diagrama cujo foco é a organização estrutural de objetos que enviam e recebem mensagens, exibindo assim, tais objetos e as ligações entre eles, bem como as respectivas mensagens, é o diagrama de

a) componentes.

b) colaboração.

c) objetos.

d) atividades.

e) caso de uso.

17. (ESAF/2008/AFC/STN/TI/Infraestrutura) O diagrama UML que apresenta objetos e suas ligações mútuas, evidenciando a sequência das mensagens trocadas por meio de números de sequência, é o

a) Diagrama de sequência.

b) Diagrama de estado.

c) Diagrama de colaboração.

d) Diagrama de caso de uso.

e) Diagrama de atividade.

18. (ESAF/2008/AFC/STN/TI/Infraestrutura) Considere o seguinte contexto: “Um cliente pode comprar vários livros”. Em um diagrama de classes, este é um exemplo de relacionamento do tipo

a) Agregação.

b) Generalização.

c) Especialização.

d) Associação.

e) Dependência.



19. (ESAF/2008/AFC/STN/ TI – Desenvolvimento de Sistemas) Em UML, o mecanismo que permite a criação de novos tipos de blocos de construção para problemas específicos, a partir dos já existentes, denomina-se

a) adorno.

b) estereótipo.

c) restrição.

d) especificação.

e) dependência.

20. (FUNRIO/Analista – Área S4/MPOG/2009) Os modelos ágeis de desenvolvimento de software foram projetados para atender a quatro tópicos-chave. Qual das alternativas NÃO É um tópico-chave?

A) Importância de equipes auto-organizadas que têm controle sobre o trabalho que executam.

B) Automatização da documentação dos sistemas em bases de conhecimento.

C) Comunicação e colaboração entre os membros da equipe e entre os profissionais e seus clientes.

D) Reconhecimento de que modificações representam uma oportunidade.

E) Ênfase na entrega rápida de softwares que satisfaçam ao cliente.

Com relação a conceitos gerais de engenharia de software, julgue os itens a seguir.

21. (CESPE/TRT - 10ª REGIÃO (DF e TO) - Analista Judiciário - Tecnologia da Informação/2013) As atividades fundamentais relacionadas ao processo de construção de um software incluem a especificação, o desenvolvimento, a validação e a evolução do software.

22. (CESPE/ 2013 /TRT - 10ª REGIÃO (DF e TO)/Analista Judiciário - Tecnologia da Informação) O ciclo de vida de um software, entre outras características, está relacionado aos estágios de concepção, projeto, criação e implementação.

23. (CESPE/TRE-BA/Analista de Sistemas/2010) Com relação à engenharia de software, julgue o item a seguir. Entre os desafios enfrentados pela engenharia de software estão lidar com sistemas legados, atender à crescente diversidade e atender às exigências quanto a prazos de entrega reduzidos.



24. (ESAF/MPOG/2008) O processo da engenharia de sistemas possui importantes diferenças em relação ao processo de desenvolvimento de software, principalmente no que se refere às suas fases. Indique a opção que representa as fases do processo da engenharia de sistemas.

a) Comunicação, Planejamento, Modelagem, Construção e Implantação.

b) Análise de requisitos, Projeto do sistema, Projeto do programa, Codificação, Testes de Unidades e de Integração, Teste do sistema, Teste de Aceitação, Operação e Manutenção.

c) Definição de Requisitos, Projeto de sistemas e de software, Implementação e testes de unidades, Integração e testes de sistemas, Operação e manutenção.

d) Análise dos requisitos do sistema, Projeto da arquitetura do sistema, Codificação e testes do sistema, Integração e teste do sistema, Teste de qualificação do sistema, Instalação do sistema e Descontinuação do sistema.

e) Definição de requisitos, Projeto do sistema, Desenvolvimento de subsistemas, Integração do sistema, Instalação do sistema, Evolução do sistema e Desativação do sistema.

25. (CESPE/2013/TRT - 10ª REGIÃO (DF e TO)/Analista Judiciário - Tecnologia da Informação) Com relação a conceitos gerais de engenharia de software, julgue os itens a seguir.

A engenharia de software engloba processos, métodos e ferramentas. Um de seus focos é a produção de software de alta qualidade a custos adequados.

26. (CESPE/MPE-RN/Gestão e Análise/2010) O modelo em espiral difere principalmente dos outros modelos de processo de software por

a)não contemplar o protótipo.

b)reconhecer explicitamente o risco.

c)não ter fases.

d)possuir uma fase evolucionária.

e)não contemplar o projeto do produto.

27. (CESPE/ 2013 /TRT - 10ª REGIÃO (DF e TO)/Analista Judiciário - Tecnologia da Informação) Tendo em vista que o desenvolvimento de um software compreende várias fases, que vão desde a definição básica até o uso do software, e que, nesse processo, diversos modelos, métodos e procedimentos de construção podem ser utilizados, julgue os itens subsecutivos.

No ciclo de vida da primeira versão do modelo em espiral, a etapa de análise de riscos é realizada dentro da fase de desenvolvimento.



28. (CESPE - 2013 - TRT - 10ª REGIÃO (DF e TO) - Analista Judiciário - Tecnologia da Informação)

Tendo em vista que o desenvolvimento de um software compreende várias fases, que vão desde a definição básica até o uso do software, e que, nesse processo, diversos modelos, métodos e procedimentos de construção podem ser utilizados, julgue os itens subsecutivos.

No modelo prototipação, a construção de software tem várias atividades que são executadas de forma sistemática e sequencial.

29. (ESAF/STN/Analista de Finanças e Controle/Governança e Gestão em TI/2013) O desenvolvimento ágil de software fundamenta-se no Manifesto Ágil. Segundo ele deve-se valorizar:

a) mudança de respostas em vez do seguimento de um plano.

b) indivíduos e interações em vez de processos e ferramentas.

c) documentação extensiva operacional em vez de software funcional.

d) indivíduos e intenções junto a processos e ferramentas.

e) seguimento de um plano em vez de resposta a mudança.

30. (FUNRIO/Analista – Área S4/MPOG/2009) Sobre o teste caixa branca de software, é correto afirmar que

A) é baseado em um exame rigoroso do detalhe procedimental.

B) refere-se a testes que são conduzidos na interface do software.

C) examina apenas algum aspecto fundamental do sistema.

D) elimina qualquer possibilidade de incorreção do sistema.

E) é conduzido nas instalação dos usuários finais, sem a presença dos desenvolvedores.

31. (FUNRIO/Analista – Área S4/MPOG/2009) A métrica de pontos de função que mede a funcionalidade entregue por um sistema pode ser usada para

A) verificar o atendimento do sistema aos requisitos do usuário.

B) garantir o cumprimento de metas no cronograma de desenvolvimento.

C) prever o número de componentes e/ou de linhas de código do sistema.

D) selecionar a melhor plataforma de hardware e software básico para o sistema.

E) validar a escolha da linguagem de programação para o desenvolvimento do sistema.



32. (FUNRIO/2013/ MPOG - Analista de Tecnologia da Informação ) Na Análise de Pontos de Função, fatores de ajustamento são usados para fornecer uma indicação da complexidade do problema. Tais fatores de ajustamento são baseados em 14 características gerais do sistema como, por exemplo, Comunicação de Dados e Desempenho. Qual das alternativas abaixo NÃO é uma característica geral do sistema usada no cálculo do valor do fator de ajustamento?

a) Entrada de dados online.

b) Reusabilidade.

c) Facilidade operacional.

d) Processamento complexo.

e) Disponibilidade 24x7.

33. (FUNRIO/2013/ MPOG/Analista de Tecnologia da Informação / Engenharia de Software ) No processo unificado de desenvolvimento de software, qual é a fase em que o planejamento do projeto é completado, o domínio do negócio é analisado e os requisitos do sistema são ordenados considerando-se prioridade e risco?

a) Concepção.

b) Elaboração.

c) Construção.

d) Transição.

e) Produção.

34. (FUNRIO/2013/ MPOG - Analista de Tecnologia da Informação / Engenharia de Software) Geralmente, um caso de uso tem diversas maneiras de ser realizado. Qual é a denominação dada à descrição de uma das maneiras pelas quais o caso de uso pode ser realizado, também chamado de instância de um caso de uso?

a) Panorama.

b) Quadro.

c) Cenário.

d) Protótipo.



e) Iteração.

35. (FUNRIO/Analista – Área S4/MPOG/2009) No contexto do projeto de software no nível de componente, a medida qualitativa do grau em que as classes são conectadas entre si, que cresce quando as classes e componentes tornam-se mais interdependentes, é denominada

A) acoplamento.

B) coesão.

C) abstração.

D) modularidade.

E) conectividade.

36. (FCC/Assembleia Legislativa do Estado de São Paulo –Agente Técnico Legislativo – Tecnologia da Informação/2010) São consideradas metodologias ágeis de desenvolvimento de software:

a) XP e UP.

b) SCRUM e DSDM.

c) SCRUM e RUP.

d) DSDM e Cascata.

e) Cascata e PRINCE2.

37. (CEPERJ/2010/CEDAE/Analista de Sistemas - Processos) Um paradigma da Engenharia de Software é representado por um método sequencial e sistemático, em que o resultado de uma fase é utilizado como entrada da fase seguinte. Ele inicia no nível de sistemas e avança ao longo da análise, projeto, codificação, teste e manutenção. Esse paradigma é conhecido por método:

A) Espiral

B) Clássico

C) Incremental

D) Estruturado por objetivos

E) Orientado por interatividade

38. (FUNRIO/2013/MPOG/Analista de Tecnologia da Informação) Considere o seguinte problema encontrado em projetos de desenvolvimento de software: “Projetos reais raramente seguem um fluxo sequencial. Apesar de um modelo linear poder acomodar a iteração, ele o faz indiretamente. Como resultado, as modificações podem causar



confusão à medida que a equipe de projeto prossegue.” Esse é um dos problemas que são algumas vezes encontrados quando é aplicado o modelo de desenvolvimento

a) em cascata.

b) ágil.

c) espiral.

d) incremental.

e) unificado.

39. (Consulplan/Pref. Manhuaçu/2010) Em relação aos Projetos de Sistemas de Software, assinale a sequência correta de desenvolvimento de um sistema:

A) Análise, Projeto, Implementação, Testes, Instalação/Implantação

B) Projeto, Análise, Implementação, Instalação/Implantação, Testes

C) Análise, Projeto, Implementação, Instalação/Implantação, Testes

D) Projeto, Implementação, Análise, Instalação/Implantação, Testes

E) Testes, Análise, Projeto, Implementação, Instalação/Implantação

40. (Cesgranrio/Funasa/2009) À luz da Engenharia de Software, o ciclo de vida clássico, também chamado de modelo sequencial linear ou modelo em cascata, é um paradigma aplicável ao desenvolvimento de sistemas de informações que

(A) enfatiza a análise de riscos, que é feita no início do projeto e revisada a cada fase, incluindo um plano de ataque e ações de mitigação dos riscos, aumentando as chances de sucesso do projeto.

(B) prevê uma sequência (ou cascata) de entregas de versões do sistema ao longo do desenvolvimento do mesmo, o que proporciona uma avaliação de progresso baseada em código funcionando, em vez de quantidade de documentação gerada.

(C) exige que todos os requisitos sejam conhecidos e corretamente especificados no início do ciclo de vida, dificultando a acomodação de mudanças que surjam nas fases posteriores.

(D) foi sempre pouco utilizado na prática, pois se apoia em analogias com práticas de engenharia convencional que não se aplicam bem ao desenvolvimento de sistemas de informação.

(E) utiliza a estratégia dividir para conquistar (divide to conquer), prevendo que cada fase do ciclo de vida seja desdobrada em um miniciclo de vida



sequencial completo, formando uma cascata de ciclos de vida até o limite adequado para lidar com a complexidade do sistema.

41. (ESAF/CGU/ Analista de Finanças e Controle/Desenvolvimento de Sistemas da Informação/2012) A escolha de um modelo é fortemente dependente das características do projeto. Os principais modelos de ciclo de vida podem ser agrupados em três categorias principais:

a) sequenciais, cascata e evolutivos.

b) sequenciais, incrementais e ágeis.

c) sequenciais, incrementais e evolutivos.

d) sequenciais, ágeis e cascata.

e) cascata, ágeis e evolutivos.

42. (Cesgranrio/Petrobrás/Processo de Negócios/2010) Existem vários Modelos de Ciclo de Vida do Processo de Software. O desenvolvimento em espiral é um modelo

(A) iterativo.

(B) para modificar requisitos.

(C) para analisar componentes.

(D) para analisar interface gráfica.

(E) para modularizar o sistema.

43. (ESAF/SEFAZ-CE/2007) Analise a seguinte descrição relacionada ao modelo espiral para a engenharia de software.

O modelo espiral para a engenharia de software, além de abranger as características do ciclo de vida clássico e o da prototipação, apresenta um novo elemento, denominado _____________, que faltava a esses paradigmas.


a) análise de riscos

b) planejamento

c) engenharia

d) projeto

e) teste

44. (ESAF/2007/SEFAZ-CE) Analise a descrição a seguir.




O paradigma do ciclo de vida clássico da engenharia de software abrange seis atividades. Na atividade de _____________ são traduzidas as exigências de uma representação do software que podem ser avaliadas quanto à qualidade antes que se inicie a codificação.


a) análise

b) engenharia de sistemas

c) teste e análise de riscos

d) coleta de requisitos

e) projeto

45. (Cesgranrio/Petrobrás/Engenharia de Software/2010) O modelo de ciclo de vida em cascata

(A) enfatiza a realização sequencial das atividades do desenvolvimento de um produto de software.

(B) enfatiza a comunicação estreita com o cliente durante o desenvolvimento do produto de software.

(C) envolve a ideia principal de criar um protótipo executável e, por meio de transformações sucessivas, chegar ao sistema completamente implementado.

(D) envolve a análise dos riscos envolvidos no desenvolvimento dos requisitos identificados para produto de software.

(E) recomenda a geração de versões incompletas do sistema, que podem ser passadas para o usuário final, o que permite a retroalimentação do processo de desenvolvimento.

46. (Cesgranrio/BNDES/Desenvolvimento/2009) No ciclo de vida em cascata, o custo de correção é menor na fase de

(A) testes.

(B) transição.

(C) implementação.

(D) requisitos.

(E) manutenção.

47. (FGV/FIOCRUZ/Tecnologista em Saúde - TI - Sistemas de Informação / Engenharia de Software /2010) A figura seguinte ilustra um modelo de processo, que prescreve um conjunto de elementos de processo como atividades de arcabouço, ações de engenharia de software, tarefas, produtos de trabalho, mecanismos de garantia de qualidade e de controle de modificações para cada projeto.



Esse modelo é conhecido como Modelo:

a) por funções.

b) em cascata.

c) incremental.

d) em pacotes.

e) por módulos.

48. (FUMARC/Analista de Sistemas/2004) Este trecho foi extraído do livro GHEZZI, Fundamentals of Software Engineering, pg 371:

“O modelo waterfall teve um importante papel por incorporar a disciplina ao processo de desenvolvimento de software e, dessa forma, superar o desestruturado processo de codificar-e-corrigir. Esse modelo introduziu duas contribuições fundamentais para o processo de software: primeiro que o processo de desenvolvimento de software deve ser submetido à disciplina, planejamento e gerenciamento, e, segundo, que a implementação de um sistema deve ser adiada até que todos os objetivos estejam bem entendidos.”

Marque a alternativa que representa uma ordem ascendente de etapas de desenvolvimento defendidas pelo modelo waterfall.

a) análise de requerimentos, codificação, integração e testes.

b) codificação, análise de requerimentos, integração e testes.

c) integração e testes, análise de requerimentos, codificação.

d) análise de requerimentos, integração e testes, codificação.

49. (CESPE/2008/SERPRO) O modelo em cascata consiste de fases e atividades que devem ser realizadas em sequência, de forma que uma atividade é requisito da outra.

50. (Cesgranrio/BR Distribuidora/Infraestrutura/2008) Considere a sequência de atividades e eventos apresentada a seguir.

• Projeto de concepção de um novo software de prateleira

• Projeto de desenvolvimento do novo software



• Projeto de marketing de lançamento do software

• Distribuição do software por dois anos

• Projeto de alteração das funcionalidades do software

• Projeto de marketing do software ampliado para atingir novos segmentos de mercado

Esta sequência de atividades é conhecida como

(A) ciclo de vida do produto.

(B) ciclo de vida de projetos.

(C) ciclo de projetos.

(D) projetos de ciclo de vida.

(E) projetos de produtos.

51. (FUMARC/CEMIG/Analista de TI Junior/2010) Sobre modelos de processo de desenvolvimento de software, assinale a alternativa INCORRETA:

a) O Scrum é um processo de desenvolvimento ágil de software baseado em grupos de práticas e papeis pré-definidos. Ele é um processo iterativo e incremental para gerenciamento de projetos e desenvolvimento de sistemas, onde cada sprint é uma iteração que segue um ciclo PDCA (Plan, Do, Check, Act) e entrega um incremento de software pronto.

b) O design centrado no usuário (UCD) é uma abordagem do processo de desenvolvimento de software baseada no entendimento explícito dos usuários, tarefas, e tem como objetivo principal o casamento entre o modelo conceitual embutido no sistema pelo projetista e o modelo mental do usuário.

c) Programação extrema (XP – extreme programming) é um processo de desenvolvimento ágil baseado em feedback rápido, e simplicidade; com enfoque explícito em tempo, custo e qualidade no desenvolvimento, que são alcançados através de uma definição rígida do escopo das funcionalidades da aplicação.

d) O modelo em espiral é um processo de desenvolvimento de software que intercala etapas de projeto e prototipação, combinando conceitos de desenvolvimento top-down e bottom-up, e permitindo, desta forma, análise de riscos e estimativas do progresso do trabalho mais realistas.

52. (FUMARC/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.

53. (UEL/POSCOMP/2010) Sobre o Ciclo de Desenvolvimento de Software, é correto afirmar:

I. O desenvolvimento em cascata tem como base a ideia de desenvolver uma implementação inicial, mostrar e discutir tal implementação com o usuário e fazer seu aprimoramento por meio de versões subsequentes, até que um sistema adequado tenha sido desenvolvido.

II. No modelo de processo de desenvolvimento em espiral, cada loop na espiral representa uma fase do processo de software. Este modelo exige a consideração direta dos riscos técnicos em todos os estágios do projeto e, se aplicado adequadamente, deve reduzir os riscos antes que eles se tornem problemáticos.

III. O Rapid Application Development (Desenvolvimento Rápido de Aplicação) é um modelo de processo se software incremental que enfatiza um ciclo de desenvolvimento rápido. Este modelo é uma adaptação de modelo cascata, no qual o desenvolvimento rápido é conseguido com o uso de uma abordagem de construção baseada em componentes.

IV. O modelo incremental combina elementos do modelo em cascata aplicado de maneira iterativa. Em um processo de desenvolvimento incremental, os clientes identificam (esboçam) as funções a serem fornecidas pelo sistema e a importância das mesmas. Em seguida, é definida uma série de estágios de entrega, com cada estágio fornecendo um subconjunto das funcionalidades do sistema.

Assinale a alternativa correta.

a) Somente as afirmativas I e II estão corretas.

b) Somente as afirmativas I e III estão corretas.

c) Somente as afirmativas III e IV estão corretas.

d) Somente as afirmativas I, II e IV estão corretas.

e) Somente as afirmativas II, III e IV estão corretas.

54. (Fumarc/Prefeitura de Governador Valadares/Analista de Sistemas/2010) Segundo Larman, o Processo Iterativo organiza o trabalho de um projeto de desenvolvimento de software em quatro fases ou marcos principais. Sobre estas fases, assinale a alternativa INCORRETA:

a) Elaboração —implementação iterativa da arquitetura, resolução dos riscos mais altos, identificação da maioria dos requisitos e escopos, e estimativas mais realistas.

b) Construção — implementação iterativa dos elementos restantes mais fáceis e de baixo risco e preparação para distribuição.




c) Transição — inclui os testes beta e distribuição.

d) Concepção — apresenta uma visão refinada do sistema, casos de negócio, escopo do projeto e estimativas bem definidos.

55. (Cesgranrio/BNDES/Desenvolvimento/2008) Que situação favorece a escolha do uso de XP para um projeto de desenvolvimento de software, em oposição à escolha do RUP ou do modelo Cascata?

(A) Equipe do projeto localizada em diferentes cidades e com poucos recursos de colaboração.

(B) Equipe do projeto formada por pessoas com alto grau de competitividade.

(C) Cliente do projeto trabalhando em parceria com a equipe do projeto e sempre disponível para retirar dúvidas.

(D) Requisitos do software com pequena probabilidade de mudanças.

(E) Presença de um processo organizacional que exige a elaboração de vários documentos específicos para cada projeto.

56. (Cesgranrio/MD/2009) A fase que deve acontecer primeiro no desenvolvimento de sistemas de uma empresa que utiliza o modelo de ciclo de vida em cascata é a de

(A) testes.

(B) análise e projeto.

(C) especificação de requisitos.

(D) implantação.

(E) implementação.

57. (Cesgranrio/Petrobrás/Processo de Negócio/2010) No Ciclo de Vida Clássico, também chamado de Modelo Sequencial Linear ou Modelo Cascata, é apresentada uma abordagem sistemática composta pelas seguintes atividades:

(A) Análise de Requisitos de Software, Projeto, Geração de Código, Teste e Manutenção.

(B) Modelagem e Engenharia do Sistema/Informação, Análise de Requisitos de Software, Projeto, Geração de Código, Teste e Manutenção.

(C) Modelagem e Engenharia do Sistema/Informação, Projeto, Geração de Código, Teste e Manutenção.

(D) Levantamento de Requisitos de Software, Projeto, Geração de Código e Manutenção e Análise de Requisitos de Software.

(E) Levantamento de Requisitos de Software, Projeto, Geração de Código, Teste Progressivo e Manutenção.



GABARITO

1. Letra E.

2. Item correto.

3. Item errado.

4. Letra B.

5. Item errado.

6. Letra B.

7. Item correto.

8. Letra B.

9. Letra D.

10. Letra E.

11. Letra B.

12. Letra C.

13. Letra A.

14. Letra D.

15. Letra A.

16. Letra B.

17. Letra C.

18. Letra D.

19. Letra B.

20. Letra B.

21. Item correto.

22. Item correto.

23. Item correto.

24. Letra E.

25. Item correto.

26. Letra B.

27. Item correto.

28. Item errado.

29. Letra B.

30. Letra A.

31. Letra C.

32. Letra E.

33. Letra B.

34. Letra C.

35. Letra A.

36. Letra B.

37. Letra B.

38. Letra A.

39. Letra A.

40. Letra C.

41. Letra C.

42. Letra A.

43. Letra A.

44. Letra E.

45. Letra A.

46. Letra D.

47. Letra B.

48. Letra A.

49. Item correto.

50. Letra A.

51. Letra C.

52. Letra B.

53. Letra E.

54. Letra D.

55. Letra C.

56. Letra C.

57. Letra B.


ANÁLISE E PROJETO DE SISTEMAS

Documents

Transcript of ANÁLISE E PROJETO DE SISTEMAS