Um risco é um potencial para a perda ou os danos a uma organização das ameaças materialized. Arriscar tentativas da análise de identificar todos os riscos e de quantify então a severidade dos riscos. Uma ameaça porque nós vimos é um evento prejudicial possível. Se ocorrer, explora o vulnerability na segurança de um sistema por computador.
Identificação do risco:
1. Riscos do software: Conhecimento dos riscos os mais comuns associados com o desenvolvimento do software, e a plataforma que você está trabalhando sobre.
2. Riscos do negócio: A maioria de riscos da terra comum associaram com o negócio usando o software
3. Riscos testando: Conhecimento dos riscos os mais comuns associados com o software que testa para a plataforma que você está trabalhando sobre, ferramentas que estão sendo usados, e métodos do teste que estão sendo aplicados.
4. Risco prematuro da liberação: A abilidade de determinar o risco associou com liberar o software insatisfatório ou untested Prodicts.
5. Métodos do risco: As estratégias e as aproximações para identificar riscos ou problemas associaram com executar e tecnologia de informação operando-se, produtos e processo; avaliando sua probabilidade, e iniciar estratégias testar aqueles riscos.
Traceability significa que você gostaria segue para a frente e para trás como e onde todo o workproduct cumpre os sentidos do produto precedendo (da fonte). A matriz tratar do onde, quando como você tem que se fazer yourself, uma vez que você sabe onde.
Tomada por exemplo a exigência do UserFriendliness (F). Desde que o F é um conceito complexo, não é resolvido por apenas uma projet-solução e não é resolvido por uma linha do código. Muitas projet-soluções parciais podem contribuir a esta exigência e muitos grupos das linhas do código podem contribuir-lhe.
Exigência-Projetar a matriz de Traceability põe sobre um lado (por exemplo à esquerda) as secundário-exigências que são supostas junto para resolver a exigência do F, junto com outras exigências (secundárias). No outro lado (por exemplo alto) você especifica todas as soluções do projeto. Agora você pode conectar nos crosspoints da matriz, que projetam soluções resolvem (mais, ou menos) toda a exigência. Se uma solução do projeto não resolver nenhuma exigência, deve ser suprimida, porque é de nenhum valor.
Tendo esta matriz, você pode verificar se qualquer exigência tenha pelo menos uma solução do projeto e verificando as soluções você possa ver se a exigência está resolvida suficientemente por este (ou jogo de) projetos conectados.
Se você tiver que mudar qualquer exigência, você pode ver que projetos são afetados. E se você mudar qualquer projeto, você pode verificar que exigências podem ser afetadas e visto o que o impacto é.
Em uma matriz de Traceability do Projet-Código você pode fazer o mesmo para manter o traço de como e de que o código resolve um projeto particular e como as mudanças no projeto ou no código se afetam.
Demonstra que o sistema executado se encontra com as exigências de usuário.
Saques como uma única fonte para finalidades seguindo.
Identifica aberturas no projeto e em testar.
Impede atrasa no timeline do projeto, que pode ser causado tendo que backtrack para encher as aberturas
