CSC E-CNS 1º, 2º e 3º Nível de Integração

Apresentação em tema: "CSC E-CNS 1º, 2º e 3º Nível de Integração"— Transcrição da apresentação:

1 CSC E-CNS 1º, 2º e 3º Nível de Integração
CE-230 Qualidade, Confiabilidade e Segurança de Software 2° Semestre de 2006 Componente de Software de Computador de Comunicação, Navegação, Vigilância CSC E-CNS 1º, 2º e 3º Nível de Integração Carla Berkenbrock Emília Colonese Gian Berkenbrock Rovedy Silva

2 ROTEIRO Introdução (Motivação, Contextualização, Objetivo e Título) Comparação de Estimativas Artefatos RUP - PDT, PGQ e CUT Documentação SoDA Análises de Sensitividade Integração - Testes (1º, 2º e 3º nível) Conclusões e Recomendações

3 INTRODUÇÃO Contextualização
Objetivo: Mostrar as atividades qualidade, confiabilidade e segurança relacionadas ao processo de desenvolvimento do CSC E-CNS visando melhorar a eficiência e reduzir o desperdício de recursos envolvidos. Título: CSC – COMUNICAÇÃO, NAVEGAÇÃO E VIGILÂNCIA DA ESTAÇÃO DE CONTROLE (E-CNS EC)

4 Por que os processos de Qualidade de software fracassam?
INTRODUÇÃO Motivação Por que os processos de Qualidade de software fracassam? Ausência de gerência de qualidade independente; Ausência de profissionais capacitados em qualidade de software; Métricas de qualidade aplicadas tardiamente no desenvolvimento do sistema; Falta de um modelo corporativo de Controle de Qualidade; Ausência de procedimentos de testes automatizados; Deficiência no planejamento de testes; e Ausência de um ambiente de testes isolado. Por que os processos de Qualidade de software fracassam? Ausência de gerencia de qualidade independente Ausência de procedimentos de Testes automatizados Qualidade é sempre aplicada tardiamente no desenvolvimento Ausência de profissionais capacitados em qualidade de software

5 COMPARAÇÃO DE ESTIMATIVAS
Tempo previsto: + de 5 meses Casos de Uso Previsto: 18 (Completo) Tempo realizado: 4 meses Casos de Uso Implementado: 15 (Incompleto)

6 ARTEFATO - PLANO GARANTIA DA QUALIDADE
Documentação Base PD, PDT, SPE, ESU Métricas IBM - Rational Test RealTime IBM - Rational Quality Architect Plano de Revisão e Auditoria Equipe E-CNS Ferramentas, Técnicas e Metodologias Metodologia RUP (Rational Unified Process) Testes e Validação Atualização do artefato Plano de Testes Gerenciamento de Riscos Atualização do artefato Lista de Riscos Cronograma Planejar projeto Gerente de projeto Desenvolver PGQ Plano de Garantia da Qualidade O Plano de Garantia de Qualidade contém todas as informações necessárias para realizar as atividades de garantia de qualidade do projeto. Ele contém: 1) o Plano de Revisão e Auditoria; 2) Faz referência a uma série de outros artefatos desenvolvidos durante a fase de Iniciação.

7 ARTEFATO - PLANO DE TESTES
Itens-alvo de Teste Definir Missão de Avaliação O banco de dados que armazena o mapa móvel deve suportar operações 24x7 e ter um tempo de resposta às solicitações considerado adequado pelo requisito tempo de resposta do SSC VANT-EC-SAME. Critérios de Êxito Verificar se o mapa móvel suporta uma solicitação de atualização de dados de vigilância no cenário (mapa móvel) do processo que a E-VIG está executando no momento. Objetivo do Tipo de Teste Atualização de Dados de Vigilância A USC E-VIG deve conseguir recuperar informações de rota através da USC E-MPM e transmitir mensagens de alarme para a E-COM. Critérios de Êxito Verificar se a USC E-NAV suporta o monitoramento de algum desvio na rota planejada que está sendo realizada pelo VANT. Objetivo do Tipo de Teste Monitoramento de Desvio Rota O plano de teste é gerado na disciplina de Teste no fluxo de trabalho de Definir missao de avaliação. Várias atividades alimentam este plano de teste. Plano de Teste tem como um dos objetivos ganhar a aceitação e aprovação dos envolvidos no esforço de teste. Conteúdo: 1) Itens-alvo de teste 2) Estratégia de teste São testes de funcionalidades O banco de dados que armazena o mapa móvel deve suportar operações 24X7 e ter um tempo de resposta considerado adequado pelo requisito tempo de resposta do SSC VANT-EC-SAME. Critérios de Êxito Verificar se o mapa móvel suporta uma solicitação de consulta da situação dos objetos estáticos e dinâmicos, constantes de um determinado cenário (mapa móvel) em processo pela E-VIS. Objetivo do Tipo de Teste Recuperação de Dados para Visualização

8 Verificar abordagem do teste
ARTEFATO - CASO DE USO TESTE Monitoramento de Desvio Rota Pré-condição/Pós condição Entradas e instruções de teste: 1. Receber/processar dados de navegação. 2. Verificar e validar dados recebidos nas USC; Resultados esperados Espera-se que o USC E_NAV seja capaz de disponibilizar dados de navegação. Verificar abordagem do teste Lista de idéias de teste Plano de Teste Define detalhes do teste Analista de Teste Caso de Teste Caso de Teste É a definição de um conjunto específico: - inputs de teste, - condições de execução - e resultados esperados, identificados com a finalidade de avaliar um determinado aspecto de um Item de Teste-alvo. Pre-condicao/Pos-condicao Inputs de teste 1. Receber/processar dados de navegação. 2. Verificar e validar dados recebidos nas USC; Resultados esperados Espera-se que o USC E_NAV seja capaz de disponibilizar dados de navegação.

9 ANÁLISES DE SENSITIVIDADE - MÉTRICAS
FATORES DE QUALIDADE x MÉTRICAS HALSTEAD V(g) LINES& COMMENT

10 A densidade de comentário recomendada por linha de código é de 20%.
ANÁLISES DE SENSITIVIDADE - MÉTRICAS Complexidade Computacional do Código Fonte (Halstead Metrics) Medida de complexidade a partir de operandos e operadores no módulo. Exemplo: Program Length ou Size (N) = operandos únicos (N1) + operadores únicos (N2). Size TopCapsule E-CNS = 1274. Complexidade Ciclomática V(g) A contagem dos desvios condicionais de um módulo de software recomendada é 10. V(g) TopCapsule E-CNS = 8,85. Nível do Programa (Lines/Comments) A densidade de comentário recomendada por linha de código é de 20%. Somente comentários TopCapsule E-CNS = 13,56 %. Somente linhas de código TopCapsule E-CNS => 465 Métrica de tamanho: Nível de arquivo (Lines/Comments) A verificação dos comentários aumenta a legibilidade do código, facilitando o trabalho em equipe resultando em maior manutenibilidade e menor probabilidade de inserção de novos erros. A densidade mínima de comentários relevantes por linha de código recomendada é de 20%. Métrica de Complexidade: Complexidade Ciclomática -V(g) Nível de complexidade de um código-fonte segundo as métricas definidas por McCabe. Nada mais é do que a contagem dos desvios condicionais de um módulo de software+1 Níveis de aninhamentos Expressa a profundidade de aninhamentos de instruções condicionais (seleções e repetições). “Total de linhas de código (somente) para o E-CNS => 5.743”

11 DOCUMENTAÇÃO DO E-CNS - SODA
Visão Lógica Visão Física

12 “Foi necessário fazer reengenharia do sistema em cada integração”
TESTE DE INTEGRAÇÃO – Redução de Escopo Monitoramento de Desvio Rota Informa Posição Informa Velocidade Monitoramento de Rota CSC E-CNS ICSC EC SSC VANT-EC-SAME “Foi necessário fazer reengenharia do sistema em cada integração”

13 TESTE DE INTEGRAÇÃO - 1º NÍVEL DE INTEGRAÇÃO
Monitoramento de Desvio Rota

14 TESTE DE INTEGRAÇÃO - 2º NÍVEL DE INTEGRAÇÃO
Informa Posição/Velocidade

15 TESTE DE INTEGRAÇÃO - 3º NÍVEL DE INTEGRAÇÃO
Monitoramento de Rota

16 CONCLUSÃO Os fatores de complexidade ambiental configurados para a estimativa de custo foram super-estimados. A utilização do Processo Unificado da Rational, da ferramenta CASE e do conhecimento adquirido nesta disciplina, possibilitou a integração dos 3 níveis do SSC VANT-EC-SAME com qualidade. A adoção da característica de iteratividade possibilitou que falhas fossem previamente detectadas e corrigidas sem custo de tempo e qualidade para o projeto além de propiciar alta confiabilidade na integração.

17 RECOMENDAÇÕES Realizar testes automatizados através das ferramentas disponíveis no ITA; Utilizar softwares alternativos para o desenvolvimento e testes, visando ampliar o background dos alunos; e Realização dos Warm-ups e Labs antes da fase de Construção.