Questões de Concurso Para pesquisador - análise de requisitos e qualidade de software

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.

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.

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

Uma contagem de projeto de desenvolvimento mede a funcionalidade fornecida aos usuários finais do software quando da sua primeira instalação, enquanto a contagem tipo aplicação mede as funções adicionadas, modificadas ou excluídas do sistema.

Arquivos lógicos internos (ALI) e arquivos de interface externa (AIE) são grupos logicamente relacionados de informações de dados e informações de controle. Ambos são identificáveis pelo usuário e considerados funções de transação. A única diferença entre eles é que os ALI são mantidos dentro da fronteira da aplicação que está sendo contada, enquanto os AIE são mantidos fora dessa fronteira.

Cada função do tipo dado e transação é classificada de acordo com a complexidade — baixa, média e alta. Com relação à função do tipo dado, determina-se a complexidade conforme quantidade de tipos de dados e arquivos referenciados; na função tipo transação, conforme a quantidade de tipos de dados e tipos de registro.

De acordo com a técnica APF, o termo usuário engloba qualquer pessoa ou coisa que interaja com a aplicação, tais como pessoa física, hardware, ator (caso de uso), gestores de negócio ou, ainda, outra aplicação a ser atendida pelo software.

O fator ajuste adiciona aos pontos de função não ajustados cerca de 35% do seu valor, conforme a influência de 14 características gerais. A aplicação do fator de ajuste é obrigatória pela métrica APF, considerada pela ISO/IEC 14143 método padrão de medição funcional.