Com relação aos modelos ágeis de processo, analise o fragmento a seguir.

“Este modelo ágil possui uma abordagem de desenvolvimento de software que premia a 'manobrabilidade' durante um jogo cooperativo de invenção e comunicação de recursos limitados, com o principal objetivo de entregar softwares úteis funcionando e com o objetivo secundário de preparar‐se para o jogo seguinte."

Segundo Pressman, esse modelo ágil de processo é denominado

Sobre a norma ISO/IEC14102, é correto afirmar que esta

Uma das utilizações mais comuns da Análise de Pontos de Função (APF), no Brasil, tem sido para

Considere os diagramas a seguir com base na UML 2.5.

Os conceitos presentes nos diagramas I e II são, respectivamente,

A Engenharia de Requisitos pode ser, em uma visão ampla, dividida em:

I. ...I... : preocupa-se com a descoberta, busca da qualidade (correção, completude, consistência, possibilidade de verificação, ordenação e rastreamento, facilidade de modificação e clareza), detalhamento, documentação, revisão e verificação dos requisitos do sistema.

II. ...II...: é um processo que estabelece e mantém acordos entre o cliente e a equipe do projeto sobre a evolução dos requisitos. Monitora o desenvolvimento e implementação dos requisitos, registrando seus atributos, status e dependência, com o objetivo de controlar o andamento e as mudanças realizadas.

Preenchem, correta e respectivamente, as lacunas I e II:

O Modelo Cascata é considerado o “avô" de todos os ciclos de vida de sistemas e propõe que, antes de produzir linha de código, deve-se fazer um trabalho detalhado de análise e projeto, de forma que, quando o código for efetivamente produzido, esteja o mais próximo possível dos requisitos do cliente. Sobre este modelo, considere:

I. É dirigido por documentação, já que é ela que determina se as fases foram concluídas ou não.

II. Prevê uma atividade de revisão ao final de cada fase para que se avalie se o projeto pode passar à fase seguinte.

III. Tem fases sequenciais, ou seja, com o passar do tempo, o processo de desenvolvimento passa de uma fase à outra, como requisitos, análise, programação, testes e implantação.

IV. São produzidos resultados tangíveis até a fase de codificação, pois sempre são estabelecidos requisitos completos antes desta fase.

Está correto o que se afirma em 

O RUP organiza o desenvolvimento de software em quatro fases, nas quais são tratadas questões sobre planejamento, levantamento de requisitos, análise, implementação, teste e implantação do software. Cada fase tem um papel fundamental para que o objetivo seja cumprido, distribuído entre vários profissionais, como o analista de sistemas, projetista etc., entre outros aspectos. Considere:

I. Desenvolve ou adquire os componentes de software. O principal objetivo desta fase é o desenvolvimento do sistema de software, com foco no desenvolvimento de componentes e outros recursos do sistema.

II. Abrange a modelagem do modelo genérico do processo. O objetivo desta fase é realizar de forma mais detalhada a análise do domínio do problema, revisando os riscos que o projeto pode sofrer. A arquitetura do projeto começa a ter sua forma básica. Indagações como “O plano do projeto é confiável?", “Os custos são admissíveis?" são esclarecidas nesta etapa.

III. Abrange a entrega do software ao usuário e a fase de testes. O objetivo desta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final. As atividades desta fase incluem o treinamento dos usuários finais e a realização de testes da versão beta do sistema visando garantir que o mesmo possua o nível adequado de qualidade.

IV. Abrange as tarefas de comunicação com o cliente e o planejamento. É feito um plano de projeto avaliando os possíveis riscos, as estimativas de custo e prazos, estabelecendo as prioridades.

Os itens numerados de I a IV acima descrevem, respectivamente, as fases: 

Na linguagem UML, o diagrama que apresenta as necessidades de hardware do sistema, como o sistema é executado e interligado com os vários dispositivos físicos e como estes componentes são configurados em tempo de execução, é chamado de diagrama de

Os requisitos não funcionais surgem por meio das necessidades dos usuários, devido a restrições de orçamento, políticas organizacionais, necessidade de interoperabilidade e fatores externos. Estes requisitos podem ser classificados como requisitos de produto, organizacionais e externos. Os requisitos externos ainda são classificados como reguladores, éticos e