Questões de Concurso Público INMETRO 2010 para Pesquisador - Análise de Requisitos e Qualidade de Software

O RUP é constituído de quatro fases, nas quais as iterações ocorrem: concepção, elaboração, construção e transição. Na primeira, identificam-se todas as entidades externas que irão interagir com o sistema e definem-se essas interações. Na segunda, são elaborados o modelo de requisitos para o sistema, a descrição da arquitetura e o plano de desenvolvimento de software. No final da fase de construção, que se relaciona ao projeto e programação do sistema, este deve estar em funcionamento e a documentação associada pronta. A fase de transição envolve os testes e a transferência do sistema para o ambiente real.

O modelo cascata representa as fases do processo separadas e encadeadas, tais como especificação de requisitos, projeto de software, implementação, teste, entre outras. A fase seguinte não pode começar antes que a fase anterior tenha terminado. O maior problema do modelo cascata é a divisão inflexível do projeto em estágios distintos, as iterações são onerosas e envolvem retrabalho.

No modelo em espiral, um exemplo de modelo iterativo, cada loop da espiral representa uma fase do processo de software. Nesse modelo, os riscos não são considerados, pois podem impactar o projeto.

XP engloba princípios como trabalhar com os clientes, utilizar metáforas, manter reuniões curtas, programar por pares, simplicidade, fazer releases em incrementos pequenos e integração contínua. O teste, uma importante atividade da engenharia de software, não é abordado na XP, o que constitui a sua maior limitação.

Embasado nas melhores práticas aceitas pelo mercado, o Scrum não é um processo ou uma técnica para o desenvolvimento de produtos, mas sim um framework que indica diversos processos e técnicas. Ele emprega uma abordagem iterativa e incremental, e trabalha com os seguinte conceitos: backlog do produto, uma lista priorizada de tudo que pode ser necessário no produto; product owner (única pessoa responsável pelo gerenciamento do backlog do produto); sprint (iteração); e times, cujo tamanho ideal, indicado pela abordagem, está entre 15 a 20 pessoas, de forma a facilitar a gestão.

Para utilizar a referida métrica, é necessário que a organização tenha um único padrão e estilo para escrever casos de uso. A pobreza na descrição dos casos de uso ou mesmo a falta de conhecimento sobre o comportamento dos requisitos pode modificar o resultado da contagem. Além disso, a empresa deve possuir histórico e gerenciamento de seus processos, caso contrário, a utilização de valores homens/hora que são sugeridos nessa métrica pode não estimar corretamente o esforço humano para a construção do produto de software.

O quantitativo de atores e a sua complexidade devem ser considerados para a aplicação dessa métrica. Um ator de complexidade simples está envolvido em regras de negócios simples e com muitas entidades do banco de dados envolvidas em seus processos. Um ator da categoria complexa está envolvido em regras complexas com poucas entidades de MER presentes. Não há regra para essa classificação, tudo deve estar embasado em experiências do passado.

Aos pontos de caso de uso, determinados a partir dos dados de atores e suas complexidades, aplicam-se fatores de complexidade ambiental e fatores de complexidade técnicos. O valor obtido em pontos de caso de uso é multiplicado pelo número de homens/hora por ponto, a fim de se estimar o número de horas que serão gastas para a construção da solução.

Os fatores de complexidade ambiental aplicados nos pontos de caso de uso englobam aspectos como motivação, facilidade de uso, facilidade para alterar e eficiência do usuário final.

Nos pontos de caso de uso, aplicam-se fatores de complexidade técnicos que englobam distribuição do sistema, reutilização do código, features de segurança, complexidade do processo interno e dificuldade de programação na linguagem.

O modelo, consistente e compatível com a ISO/IEC 15504, apresenta quatro disciplinas: engenharia de sistemas, engenharia de software, desenvolvimento integrado de produto e do processo e fontes de desenvolvimento.

O CMMI possui a representação por estágios e contínua. Na representação por estágios, que organiza as áreas de processo em seis níveis de maturidade — incompleto, realizado, gerenciado, definido, gerenciado quantitativamente e otimizado —, é possível selecionar a sequência de melhorias que convém à organização. A representação contínua define cinco níveis de maturidade — inicial, gerenciado, definido, gerenciado quantitativamente e otimizado — e aponta um caminho continuado e predefinido de áreas de processos.

A área de processo gestão de requisitos do CMMI DEV tem como propósito gerenciar os requisitos dos produtos e componentes de produto do projeto, identificando inconsistências entre esses requisitos e os planos e produtos de trabalho do projeto. São exemplos de algumas de suas práticas específicas: obter entendimento dos requisitos; obter comprometimento com os requisitos; gerenciar mudanças de requisitos; manter rastreabilidade bidirecional dos requisitos.

Desenvolvimento de requisitos é uma área de processo do CMMI DEV que tem como propósito produzir e analisar os requisitos de cliente, de produto e de componente de produto. São exemplos de algumas de suas práticas específicas: levantar os requisitos; desenvolver os requisitos de cliente; desenvolver requisitos de produto; estabelecer os requisitos de produto e de componentes de produto; alocar os requisitos de componentes de produto; identificar e analisar inconsistências entre trabalho de projeto e requisitos.

São algumas práticas específicas do processo de validação do CMMI DEV: selecionar os produtos de trabalho; estabelecer o ambiente; realizar revisão por pares; preparar para revisão por pares.

As normas NBR ISO/IEC 12207, NBR ISO/IEC 15504 e CMMI DEV constituem a base para a construção do MPS.BR. O modelo possui seis níveis de maturidade, de A a F, tem custo acessível, avaliação bienal e apresenta forte interação entre universidade e empresa.

O modelo MPS.BR está dividido em três componentes: modelo de referência (MR-MPS); método de avaliação (MA-MPS); e modelo do negócio (MN-MPS). O primeiro contém os requisitos a serem cumpridos pelas organizações que visam a conformidade com o modelo; o segundo, uma descrição das regras para a implementação do MR-MPS pelas empresas de consultoria, de software e de avaliação; e o terceiro contém o processo de avaliação, os requisitos para os avaliadores e os requisitos para averiguação da conformidade.

Gerenciar requisitos, do MPS.BR, e gestão de requisitos, do CMMI DEV, são processos similares, ambos apresentando resultados esperados semelhantes às práticas específicas do CMMI DEV. Tanto no CMMI DEV como no MPS.BR o nível de maturidade é gerenciado.

No processo desenvolvimento de requisitos, os requisitos funcionais e não funcionais de cada componente do produto são refinados, elaborados e alocados; interfaces internas e externas do produto e de cada componente do produto são definidas; conceitos operacionais e cenários são desenvolvidos.

O processo de verificação tem como propósito confirmar que um produto ou componente do produto atenderá a seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido.

A ISO/IEC 12207 apresenta os processos divididos em três grupos: primários, de apoio e organizacionais. O primeiro abrange processos básicos que se relacionam aos produtos de software, como desenvolvimento, operação e manutenção; o segundo envolve processos, como revisão e auditoria, que iniciam, em geral, depois que algum processo primário começa; já os processos organizacionais dizem respeito à operação da organização, como gerência e treinamentos.

A ISO/IEC 12207 define os processos de uma maneira hierárquica demonstrando as atividades vinculadas a cada processo, mas não define as tarefas nem o detalhamento dessas atividades.

A ISO/IEC 15504 possui cinco níveis de capacitação: executado, gerenciado, estabelecido, previsível e otimizado.

Na ISO/IEC 15504, a avaliação sob a dimensão de processo verifica a execução dos processos e considera quatro categorias de processos: engenharia, suporte, administração e organização.

Na avaliação sob a dimensão de capacidade da ISO/IEC 15504, são utilizados atributos de processo e indicadores para esses atributos, propostos na seguinte escala de capacidade: não atingido, parcialmente atingido, largamente atingido e totalmente atingido. Não existem semelhanças de avaliação com o CMMI DEV nem com o MPS.BR.