gerenciamento de projetos". Em resumo, a ideia e que praticamente todo projeto tem tres fatores de limitacao: custo, cronograma e escopo. Custo e quanto dinheiro voce tem para gastar no projeto; cronograma e quanto tempo voce tem para concluir o projeto; e escopo e o conjunto de recursos necessarios e a qualidade deles.Essas tres restricoes de projeto tem varios aliases. Por exemplo, custo tambem e conhecido como orcamento ou dinheiro. Cronograma costuma ser chamado de tempo ou duracao. E escopo e chamado algumas vezes de recursos, qualidade ou ate recursos/qualidade. Observe que essa ultima restricao pode ser (e, na verdade, geralmente e) considerada como duas restricoes distintas.Uma nocao importante e que uma alteracao em qualquer das restricoes provavelmente modificara uma das outras restricoes ou as duas. Por exemplo, se voce estiver desenvolvendo um aplicativo de software e, de repente, precisar concluir o projeto em um prazo menor que o planejado, provavelmente tera de gastar mais dinheiro (para adquirir recursos adicionais ou terceirizar parte do projeto) ou cortar na qualidade ou em alguns recursos. Se o orcamento do seu projeto for cortado, e provavel que voce tenha de estender o prazo de conclusao do projeto, remover alguns recursos ou reduzir a qualidade do projeto. Usando o paradigma de triangulo de gerenciamento de projetos, ja que a finalidade do teste de software e melhorar a qualidade de um sistema, conclui-se que os dois niveis mais altos de risco em um projeto de software sao que o projeto nao seja concluido dentro do prazo e que exceda o orcamento.Identificacao de riscosAo contrario dos meta-riscos de custo e de tempo, nos quais os eventos de risco podem ser determinados de forma gradativa (embora nada facil) decompondo-se iterativamente tarefas em subtarefas menores, a identificacao de riscos costuma ser muito menos mecanica. Em um ambiente de desenvolvimento e teste de software, ha tres abordagens principais para a identificacao de riscos: uma baseada em taxonomia, outra em cenario e uma terceira em especificacao.Uma taxonomia e simplesmente uma lista de classificacao. Considere a analogia a seguir. Voce vai viajar de aviao, por isso usa uma lista de lembretes padrao reservada para antes de cada viagem. A lista contem assertivas ou perguntas como "Estou com minha carteira de identidade?" e "Verifiquei se o voo esta no horario?"Ao longo dos anos, muitas pessoas e organizacoes criaram taxonomias de risco de software. Uma dessas listas foi criada por Barry Boehm, pioneiro e conhecido pesquisador na area de risco de projetos de software. Em 1989, Boehm identificou uma taxonomia com 10 principais riscos de software, que foi atualizada por ele em 1995. Esta e a versao de 1995:Problemas com pessoalCronogramas, orcamentos, processoSoftware comercial pronto para uso, componentes externosIncompatibilidade de requisitosIncompatibilidade com a interface do usuarioArquitetura, desempenho, qualidadeAlteracoes nos requisitosSoftware herdadoTarefas executadas externamenteCiencia da computacao exigida alem do limiteVoce deve ter observado que a lista de Boehm com os 10 principais riscos nao identifica imediatamente os riscos. Em vez disso, a taxonomia serve apenas como ponto de partida para voce comecar a pensar nos riscos que se aplicam ao seu projeto de software. Por exemplo,