Questões de Concurso Comentadas sobre processos de software em engenharia de software

m Time de Desenvolvimento de Sistemas de Software (TDSS) decidiu adotar um modelo de processo de software prescritivo como padrão para novos desenvolvimentos de sistemas. O modelo de processo adotado visa à redução do impacto de mudanças em requisitos, no qual a qualidade da documentação não é uma prioridade.
O TDSS adotou o modelo de processo:

Conhecido como um dos primeiros modelos de desenvolvimento e derivado de processos mais gerais da engenharia de sistemas o modelo cascata é conhecido assim por causa do encadeamento entre uma fase e outra. É o exemplo de um processo dirigido a planos. Com base nesse modelo, avalie as afirmações a seguir:
I - Na primeira etapa é feito o levantamento de requisitos com o cliente, para entender suas expectativas e definir quais funcionalidades devem ser implementadas no sistema.
II - O modelo cascata é inflexível, já que uma vez iniciado, todas as etapas são executadas e o primeiro resultado só é visto no final.
III - Outro problema do modelo em cascata é a falta de feedback do cliente, já que a interação dele com a equipe de desenvolvimento geralmente acontece somente no início e no fim do projeto.
Estão corretas as afirmações:

São modelos de processo de desenvolvimento de software, EXCETO: 

Segundo PRESSMAN (2011) este ciclo de vida é considerado como clássico por ter uma abordagem sequencial e sistemática para o desenvolvimento de software. Esse ciclo de vida é especificamente denominado como: 

Considere que determinada empresa de desenvolvimento de software ganhou processo de licitação para desenvolver dois sistemas de gestão para a Secretaria da Fazenda do Piauí. Na fase de elicitação de requisitos desses sistemas, o engenheiro de requisitos identificou as seguintes características no projeto:

I. O sistema será entregue somente na última fase de desenvolvimento e o teste deve ser realizado em cada fase.

II. A avaliação de risco deve ser realizada a cada iteração.

III. Devem ser usados componentes já implementados utilizando um framework de integração para os módulos.

É correto afirmar que as características estão relacionadas, respectivamente, aos seguintes modelos de desenvolvimento de software:

Há vários modelos de processo de software, sendo que cada um define um fluxo de processo que invoca cada atividade do desenvolvimento de forma diversa.
O modelo ___________, algumas vezes chamado ciclo de vida clássico, é um exemplo de processo dirigido a planos, pois deve-se planejar todas as atividades (estágios) do processo antes de começar a trabalhar nelas. Em princípio, o estágio seguinte não deve ser iniciado até que o estágio anterior seja concluído, mas, na prática, este processo não é um modelo linear simples, envolvendo o feedback de um estágio a outro. Assim, os documentos e artefatos produzidos em cada estágio podem ser modificados para refletirem as alterações em cada um deles.
Seu maior problema é a divisão inflexível do projeto em estágios distintos e por isso deve ser usado apenas quando os requisitos são bem compreendidos e é pouco provável que venham a ser radicalmente alterados durante o desenvolvimento. Um segundo exemplo de modelo de processo de software é o modelo de ___________________, que se baseia na construção de protótipos, uma versão simplificada de um sistema de software.
Embora possa ser utilizado como um modelo de processo isolado, é comumente utilizado como uma técnica que auxilia os interessados a compreender melhor o que está para ser construído, quando os requisitos estão obscuros.

Assinale a alternativa que completa, correta e respectivamente, as lacunas do texto acima.

Considere as seguintes afirmativas sobre processos de software.

I - Um exemplo de modelo de processo de software é o "modelo em cascata", assim chamado por causa do encadeamento entre uma fase e outra. Em princípio, o modelo em cascata deve ser usado apenas quando os requisitos são bem compreendidos e é pouco provável que venham a ser alterados de forma radical durante o desenvolvimento do sistema.
II - Uma categoria de processo de software são os processos ágeis, em que o planejamento não é gradativo e é mais difícil realizar mudanças de maneira a refletir as necessidades dos clientes.
III- No processo de desenvolvimento denominado prototipação, um protótipo é usado para demonstrar conceitos, experimentar opções de projeto e descobrir mais sobre o problema e suas possíveis soluções.

Quais estão corretas?

      Um analista deve escolher uma metodologia de desenvolvimento para elaborar o planejamento do ciclo de vida de um produto de software de larga escala. O sistema é inédito e o reúso de código semelhante não deve ser considerado como base para o novo desenvolvimento. O analista deve considerar, ainda, a necessidade de reduzir os riscos em todas as fases do projeto, pois é provável que os requisitos sejam aprimorados e mudem ao longo do processo. Entre os riscos a serem mitigados, está o de não ter sido contratado pessoal de software suficiente para construir o produto, além de a equipe contratada não ter experiência suficiente no desenvolvimento de produtos em larga escala. Ainda, há o risco de o fornecedor do hardware necessário ao projeto não entregar todas as estações clientes no prazo do contrato. 

Nessa situação hipotética, para a metodologia do processo de software em questão, é mais apropriado o uso do

Sobre as fases do Processo Unificado, analise as assertivas abaixo e assinale a alternativa correta.

I. Na fase de Concepção, todos os casos de uso são definidos em detalhes.

II. O Modelo de Domínio é um dos artefatos produzidos durante a fase de Elaboração.

III. A fase de Construção é responsável pela produção de diversos artefatos importantes, dentre os quais se destaca o Diagrama de Classes de Projeto. 

O Processo Unificado e diversos métodos atuais de desenvolvimento iterativo encorajam um planejamento das iterações iniciais de um projeto de forma a priorizar:

Considere as seguintes atividades:
I. Identificar os maiores riscos do projeto e, no final da fase, apresentar um modelo de requisitos para o sistema, que pode ser um conjunto de casos de uso da UML, uma descrição da arquitetura ou um plano de desenvolvimento do software.
II. Elaborar o projeto do sistema e o desenvolvimento, em paralelo, das partes do sistema e sua integração.
III. Com base em informações originadas de business cases estabelecidos para o sistema, identificar todas as entidades externas (pessoas e sistemas) que vão interagir com o sistema e definir as interações. Essas informações são usadas para avaliar a contribuição do sistema para o negócio.
Essas atividades são, correta e respectivamente, abordadas nas fases do Rational Unified Process (RUP): 

Um Analista de Sistemas atua no desenvolvimento de software utilizando diferentes processos e metodologias cujas características são: 

I. A fase de transição se concentra nas atividades necessárias para colocar o software nas mãos dos usuários. Tipicamente, essa fase inclui várias iterações, incluindo versões beta, versões de disponibilidade geral, além de correções de erros e lançamentos de aprimoramento. Um esforço considerável é gasto em atividades ligadas ao usuário: documentação de sistema, treinamento e suporte no uso inicial do produto. Neste ponto, no entanto, o feedback do usuário deve limitar-se principalmente a problemas de ajuste, configuração, instalação e usabilidade do produto. 
II. Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. A transparência requer que estes aspectos tenham uma definição padrão comum para que os observadores compartilhem um mesmo entendimento do que está sendo visto. Por exemplo: uma linguagem comum referindo-se ao processo deve ser compartilhada por todos os participantes; e aqueles que realizam o trabalho e aqueles que inspecionam o incremento resultado do trabalho devem compartilhar uma definição comum de Pronto.
III. A implementação inicial do software apoia duas atividades do processo de engenharia de requisitos: a) levantamento de requisitos, pois os usuários podem realizar experiências para ver como o sistema apoia seu trabalho, podendo ter novas ideias para os requisitos, identificar pontos positivos e negativos do software e até propor novos requisitos de sistema; b) validação de requisitos, pois a implementação pode revelar erros e omissões nos requisitos propostos, levando os usuários a crerem que sua visão inicial era incorreta e incompleta e dando a eles oportunidade de fazerem ajustes na especificação de sistema para refletir sua compreensão alterada dos requisitos. 
IV. O cliente está sempre participando do desenvolvimento do sistema; testes de unidade e de aceitação fornecem feedback sobre o sistema; oportunidades e problemas são identificados o mais rápido possível; os códigos são integrados e testados constantemente, para o caso de algum problema ser detectado, poder ser corrigido imediatamente.

As características I, II, III e IV são, respectivamente,