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

Um projeto deve ser elaborado a partir do estado da arte, ou seja, de quais são as melhores técnicas para gerenciá-lo, independentemente do contexto em que se aplica ou da necessidade específica identificada.

Em um projeto, deve sempre existir um gerente de projetos e de portfólio que se responsabilize pelo projeto, pois, geralmente, é praticamente impossível balancear demandas de qualidade com pessoal, prazo e custo.

Um projeto de alto nível de qualidade deve estar isento de adaptações excessivas de especificações, planos e demais elementos de planejamento, a fim de evitar que haja demasiadas solicitações oriundas de preocupações e expectativas das partes interessadas.

O conceito de restrição tripla de projeto envolve os elementos de escopo, tempo e custo do projeto, os quais afetam a qualidade do projeto, considerando-se que, se um desses elementos mudar, os dois outros serão também afetados.

A conhecida restrição tripla do projeto refere-se ao balanceamento de pessoal, de prazo e de custo do projeto, por intermédio dos quais a qualidade é atingida de maneira desejada por todos os envolvidos.

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.

No desenvolvimento de um produto de software, as atividades de validação são normalmente executadas somente sobre o produto final, em ambiente operacional.

A validação, atividade fundamental para a garantia da qualidade de um software, deve ser bem planejada e, durante o desenvolvimento do software, executada com eficácia.

Somente após a codificação de um componente ou de um produto de software é possível validar os requisitos identificados para esse componente ou produto.

Verificação consiste no processo de exame de um produto para a determinação de sua conformidade com as necessidades do usuário, e validação, no exame do resultado de uma atividade para a determinação de sua conformidade com os requisitos estabelecidos para essa atividade.

Revisão por pares é uma técnica de validação que demonstra que o produto correto está sendo desenvolvido.