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.

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.

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

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 á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.

a adoção de abordagem embasada na elaboração progressiva, uma vez que o escopo do projeto pode ser aumentado sempre que desejado.

a presença de uma pessoa diretamente vinculada ao projeto, que assume o papel de gerente e é responsável pelo desempenho de funções relativas aos cinco grupos de processos — iniciação , planejamento , execução , monitoramento e controle —, além do encerramento e às nove áreas de conhecimento descritas no modelo.

O framework de processo RUP (rational unified process) organiza o ciclo de vida de um produto de software desde o início de sua concepção até a sua aposentadoria, na seguinte seqüência de etapas: concepção, elaboração, construção e transição.

Para a utilização do trunk, é imprescindível apenas a utilização do sistema operacional Windows, versão 98 ou superior.

O gráfico de Milestones fornece uma visão ampla e detalhada do projeto, possibilitando uma avaliação pontual e precisa do andamento geral do projeto, o que o toma uma ferramenta útil a todos os participantes de um projeto.

O PERT-CPM é um tipo de cronograma de trabalho que relaciona as tarefas e o tempo de execução de cada uma. Além disso, ele leva em consideração as datas mais cedo e mais tarde, as folgas, as dependências e o caminho crítico.

O cronograma permite que o gerente de projeto preveja com exatidão se a data é viável com base no escopo do projeto, nos requisitos do projeto, no número de pessoas envolvidas em cada fase e na duração de cada tarefa.

A estrutura analítica de um projeto permite programar a execução paralela de tarefas, a fim de acelerar a produção.

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.