O cronograma, para um projeto específico, retrata a interação entre as fases, as etapas e as atividades a serem realizadas, e estima o tempo necessário para realizá-las.

Ponto de função é unidade de medida que tem por objetivo tomar a medição das funcionalidades fornecidas por um software independente da tecnologia utilizada para a construção desse software.

Nas fases de especificação de requisitos e projeto de alto nível, a medição funcional realizada é apenas uma projeção do que será entregue. Contudo, ao final do projeto detalhado, é possível realizar uma contagem dos pontos de função do produto final.

A análise por pontos de função não permite medir o tamanho do sistema em relação à funcionalidade fornecida ao usuário, mas permite estimar seu tamanho em qualquer fase de seu ciclo de vida.

A garantia de qualidade tem como objetivo testar os produtos de software de modo a identificar, relatar e remover os defeitos encontrados, enquanto o controle da qualidade provê a gerência sênior da organização com a visibilidade apropriada sobre o processo de desenvolvimento.

O RUP (rational unified process) é um modelo de desenvolvimento de software com visão estática que enfoca at iv id ad es que oco r rem durante o proce s so de desenvolvimento.

O documento de requisitos de software estabelece formalmente o que os desenvolvedores de sistema devem implementar e incluir a especificação resumida dos requisitos do sistema e a visão detalhada da arquitetura do sistema.

A descrição dos cenários de uso com informações acerca da utilização do sistema sob diversos pontos de vista e formas de operação deve fazer parte do levantamento dos requisitos.

O questionamento acerca da consistência, das omissões e das ambigüidades dos requisitos obtidos faz parte da função de validação dos requisitos.

A entrevista é uma técnica de elicitação de requisitos simples, eficiente e direta e, por esses motivos, pode ser usada como fonte exclusiva de informação acerca dos requisitos do sistema.

Linhas de produto e software empregam técnicas de engenharia de software para criação de um porta-fólio de sistemas de softwares similares a partir de um conjunto compartilhado de ativos de software, usando meios de produção comunal. 

Internet: <www.softwareproduclines.com> (com adaptações).

Tendo o texto acima como referência inicial, julgue o item a seguir, acerca do conceito de linhas de produto e de sua relação com os componentes de software.

O ciclo de vida de componentes de software, em uma abordagem de linha de produtos, possui foco no reúso preditivo e não no reúso oportunístico.

Linhas de produto e software empregam técnicas de engenharia de software para criação de um porta-fólio de sistemas de softwares similares a partir de um conjunto compartilhado de ativos de software, usando meios de produção comunal. 

Internet: <www.softwareproduclines.com> (com adaptações).

Tendo o texto acima como referência inicial, julgue o item a seguir, acerca do conceito de linhas de produto e de sua relação com os componentes de software.

Todo ativo de software é um componente de software de determinado domínio.

A engenharia de software é um a disciplina do conhecimento humano que aplica princípios da engenharia ao desenvolvimento de software. N o entanto, existem diferenças significativas entre as engenharias clássicas — mecânica, civil, elétrica— e a engenharia de software, muitas delas decorrentes das diferenças de natureza entre o produto ou sistema resultante da atividade das engenharias clássicas e a engenharia de software. A engenharia de software desdobrou-se em várias áreas especializadas, como as áreas de requisitos de software, de análise e projeto de software, de implementação de software, de testes de software, de gestão de configuração, entre outras. N a interface entre as engenharias clássicas e a de software insere-se a engenharia de sistemas, abordada colateralmente na ISO/IEC 12207.

Identificação, auditoria, controle, contabilização de status e gerenciamento de liberações e entregas são atividades de gerência de configuração de software que ocorrem tipicamente na ordem enunciada, quando executados para determinado item de configuração.

Com relação ao emprego de diferentes técnicas para a realização de testes de software, é correto afirmar que haverá maior diminuição da dependência de acesso às especificações arquiteturais de um sistema se o testador empregar a técnica de caixa-branca (white-box), em vez das técnicas de caixa-cinza (,gray-box) e de caixa-preta (black-box).

A engenharia de software é um a disciplina do conhecimento humano que aplica princípios da engenharia ao desenvolvimento de software. N o entanto, existem diferenças significativas entre as engenharias clássicas — mecânica, civil, elétrica— e a engenharia de software, muitas delas decorrentes das diferenças de natureza entre o produto ou sistema resultante da atividade das engenharias clássicas e a engenharia de software. A engenharia de software desdobrou-se em várias áreas especializadas, como as áreas de requisitos de software, de análise e projeto de software, de implementação de software, de testes de software, de gestão de configuração, entre outras. N a interface entre as engenharias clássicas e a de software insere-se a engenharia de sistemas, abordada colateralmente na ISO/IEC 12207.

A atividade de teste unitário de software é, conforme os modelos de ciclo de vida de software vigentes, realizada de forma mais eficaz no escopo da implementação e da construção de software — nas quais a codificação de uma unidade executável de software é feita —, quando comparada à situação em que o teste unitário é realizado simultaneamente ao teste de integração.

Visando a maior efetividade no processo de desenvolvimento, os requisitos de software são, em geral, desenvolvidos antes dos requisitos de sistema.

A área de atividade de requisitos de software apresenta maior interface com a engenharia de sistemas quando comparada à área de análise e projeto de software.

Acerca de modelos e abordagens à gestão de empreendimentos de desenvolvimento de software, julgue o item abaixo.

O modelo de gestão bazar, comparado ao modelo catedral, apresenta melhores condições para apoiar o desenvolvimento de software colaborativo, especialmente se este tiver código aberto e for aderente à abordagem de software livre. Tal modelo, comparado ao modelo catedral, apresenta ainda menor previsibilidade acerca da arquitetura do software que emerge da interação entre as pessoas.

No modelo RUP, a primeira linha de base da arquitetura de um software é produzida ao final da fase de elaboração.

Metodologias ágeis, como a XP, enfatizam a documentação de software no próprio código, que deve ser escrito por meio de ferramentas CASE voltadas ao desenvolvimento rápido de aplicações (RAD tools).