a) dependência de linguagem de programação dos componentes reusados. (errado) O middleware serve justamente para realizar a abstração e manter a independência entre as linguagens dos componentes.
b) falta de padronização dos componentes reusados. (dúvida) Também me parece um problema... afinal, é um pressuposto na engenharia de componentes que exista um padrão na criação dos componentes. Eu consideraria como um problema.
c) alto custo de desenvolvimento dos componentes reusados em comparação ao custo de integração e de teste dos mesmos. (errado) O custo de um componetne para reúso será diluído nos projetos seguintes que necessitarem do seu uso, gerando economia de recursos e tempo. O custo de integração é menor que o custo do desenvolvimento do componente.
d) confiabilidade e certificação dos componentes reusados (certo) Um componente que esteja no estágio de reuso deve necessariamente manter um nível de confiabilidade alto, mantendo-se genérico o suficiente, encapsulado e padronizado o suficiente, documentado e testado o suficiente. Caso contrário, o componente "instável" oferece risco a todos os projetos que o utilizarem.
Para Sommerville, embora a CBSE (Component-Based Software Engineering) esteja se desenvolvendo rapidamente em uma abordagem principal para o desenvolvimento de software, alguns problemas permanecem:1. Confiabilidade de componentes. Os componentes são unidades caixa-preta de programa, e o código-fonte do componente pode não estar disponível aos usuários. Nesses casos, como o usuário pode saber que um componente é confiável? O componente pode ter modos de falha não documentada que comprometa o sistema em que é usado.
2. Certificação de componentes. Estreitamente relacionada com a confiabilidade está a questão de certificação. Foi proposto que avaliadores independentes devem certificar componentes para assegurar que estes são confiáveis. Contudo, não está claro como isso pode funcionar.
3. Previsão de propriedade emergente*. Devido aos componentes serem opacos, a previsão de suas propriedades emergentes é particularmente difícil. Consequentemente, você pode descobrir que, quando os componentes são integrados, o sistema resultante tem propriedades indesejáveis que limitam seu uso.
4. Compromisso de requisitos. Geralmente, você precisa ter compromissos entre requisitos ideais e componentes disponíveis no processo de especificação e projeto do sistema. Nesse momento, ter esses compromissos é um processo intuitivo. Nós necessitamos de um método de análise estruturado e sistemático de compromissos para ajudar os projetistas a selecionar e configurar componentes.
(Fonte: Engenharia de Software, 8ed, Sommerville, Cap 19)
PS. No capítulo 2, Sommerville explica que propriedades emergentes de um sistema são características do sistema como um todo, em vez de seus componentes. São propriedades como desempenho, confiabilidade, usabilidade, segurança e proteção. Ou seja, são propriedades que não podem ser atribuídas a qualquer parte específica do sistema. Ao contrário, elas aparecem apenas após a integração de todos os componentes do sistema. O sucesso ou falha de um sistema geralmente depende dessas propriedades.
Voltando para as alternativas,
a) Errado. Se os componentes estiverem em conformidade com os padrões, a operação será independente de linguagem de programação. Componentes escritos em linguagens diferentes podem ser integrados em um mesmo sistema. (pag 292)
b) Errado. O próprio enunciado da questão destaca que os "componentes de software reusáveis padronizados". Mesmo assim, isso não deveria ser um problema pois um componente deve ter as seguintes características: Padronizado, Independente, Passível de Composiçao, Implantável e Documentado. (pag 294)
c) Errado. Explicado pelo Saulo Guerra.
d) Correta.