Projeto de Qualidade, Confiabilidade e Segurança de Software do CNS-V

 

CE-230 Qualidade, Confiabilidade e Segurança de Softwares

Prof. Adilson Marques da Cunha

 

Envolvidos:

Eliane Santiago Ramos
Oiram José Barbosa dos Santos
José Fernando Basso Brancalion
Sergio Luis Pires Barros
Wellingtonn Vergilio Fortes
Wesley de Oliveira Ruas

 

 

Instituto Tecnológico de Aeronáutica - ITA

Divisão de Ciência da Computação

 

 

 

ÍNDICE

 

 

 

 

 

I – INTRODUÇÃO

II – DESENVOLVIMENTO

 III – CONCLUSÕES e RECOMENDAÇÕES

IV – BIBLIOGRAFIA

 

 

 

 

 

 

 

 

 

 

 

 

I-                  INTRODUÇÃO

1.1 - Motivação

        Atualmente conseguir softwares no mercado com grande padrão de qualidade é difícil. Hoje poucas empresas têm certificações e a maioria desconhece totalmente o termo Qualidade, Confiabilidade, Segurança de Softwares. Este projeto tem como objetivo adequar o software CNS-V e trazer experiência para nós profissionais de Tecnologia de Informação para suprirmos as necessidades do mercado.

1.2 - Contexto

            Neste projeto será demonstrado o programa de Qualidade, Confiabilidade de Softwares que foi aplicado no sistema CNS-V conforme o padrão RUP – Rational Unified Process. Este software faz parte do conjunto de software da estação Vigilante e que no 3º nível de integração completará o Sistema Embarcado do Projeto TRIVIG.

1.3 – Objetivo

         Trazer o máximo de Qualidade, Confiabilidade e Segurança para o software do TRIVIG pois trata de um software que pode trazer acidentes catastróficos ( DOD MIL-STD-882D)  em caso de sua falha.

 1.4 – Escopo

            Será aplicada o RUP e ferramentas da Rational e métricas do Borland Together e a analise de risco FMEA. Com isso avaliaremos o nível de qualidade do software.

 

 

II – DESENVOLVIMENTO

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

A Estação Vigilante tem a função de emitir informações para o Triphibius. Ela é composta de  3 grupos de Sub-sistemas:

 

SEG – V

CTR – V

CNS - V

 

           

 

Este projeto tem a finalidade de consolidar a Qualidade do subsistema CNS – V, o qual é composto pelos seguintes subsistemas:

 

 

Comunicação

Vigilância

Navegação

 

 

 

 

 

 

 

 

         Foi definido o processo o RUP Small Projetcs da Rational à ser utilizado para o desenvolvimento e programa de qualidade do CNS-V. Este processo tem um menor número de Iterações que o processo padrão.  Este projeto foi dividido em 6 iterações: Listex 2, 3, 4, 5, 6 e Projeto Final. Estas iterações foram distribuídas nas 4 fases do RUP: Iniciação, Elaboração, Construção e Transição. E foram aplicadas as disciplinas básicas. Assim foi atendido o prazo limite.

 

 

 

 

     

 

 

 

 

 

 

 

 

 

 

 

 

Etapas

 

 

 

 

1a Fase do RUP - Iniciação

(Inception Iteraction) –  ListEx 2

 

1a/2a Fase – Iniciação/Elaboração

(Elaboration Iteraction ) - ListEx 3

 

 2a/3a Fase - Elaboração/Construção

(Elaboration to Construction Iteractions ) Avaliação (Auditoria)

 

 3a Fase – Construção

(Construction 1st Iteraction & Integration Level Zero) - ListEx 4

 

 3a Fase – Construção

(Construction 2nd Iteraction & 1st and 2nd Integration Level) - ListEx 5

 

 3a/4a Fase – Construção/Transição

(Construction to Transition 2nd and 3rd Integrations ) - ListEx 6

 

 4a Fase - Transição

(Transition Iteraction & 3rd Integration Level) – Avaliação ( Auditoria )

 

4a Fase – Transição

(TRIVIG Consolidation on the 3rd Integration Level) -  Projetos Finais

 

 

 

 

 

 

 

 

 

 

1ª Fase – Iniciação ( Listex 2 )

 

 

Nesta fase se desenvolveu o conjunto de artefatos que iriam descriminar as técnicas, padrões, normas e procedimentos no qual nos basearíamos para avaliarmos, quantificarmos e aplicarmos melhorias no software. Com isso nós definimos baeline que nosso projeto de Qualidade iria seguir.  As normas utilizadas são todas Institucionalizadas assim possibilitando posteriormente uma certificação do CNS-V. As normas atacam o CNS-V em todos aspectos: software como Produto, Processo e Serviço.

 

Grupo – COMU

 

• Oiram José Barbosa dos Santos

Norma IEEE Std 830-1998 – Norma IEEE Std 1016-1998

•  

 

• Eliane Santiago Ramos

CMMI - Nível 1 - Inicial (Staged/Continous) - CMMI - Nívvel 2 - Repetível (Staged/Continous) / CMMI - Nível 5 - Otimizado (Staged/Continous)

 

• Sergio Luis Pires Barros

Norma NBR ISO 9000 – Norma NBR 5462

 

• Wellingtonn Vergilio Fortes

Norma IEE 802.11 – Norma ECSS-E-60

 

 

Grupo – VIGI

 

• José Fernando Basso Brancalion

Norma MIL-STD-498 – Norma DOD-STD-2167A

 

• Wesley de Oliveira Ruas

Norma DHM-014-R01-2001 – Norma NSCA-007-1-2001

 

 

 

 

 

 

Artefatos

 

Grupo – COMU

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Grupo – VIGI

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1ª/2ª Fase  Iniciação/Elaboração:

 

            Foi definido o conjunto de ferramentas que auxiliaram os profissionais do grupo de qualidade de softwares. Essas ferramentas tinha como finalidade auxiliar os processos metódicos e a quantificar a qualidade do softwares em vários aspectos. Baseando-se nas características da ferramenta foi criado um plano de uso e aplicação.

 

Grupo – COMU

 

 

 

 

 

 

 

Grupo – VIGI

 

 

 

 

 

 

 

 

 

2ª/3ª Fase Elaboração/Construção

 

 

            Esta etapa foi feita a primeira auditoria do Projeto de Qualidade do

CNS-V. Esta avaliação teve como objetivo confirma aplicação das normas, técnicas, padrões e procedimentos descriminados na fase de iniciação e verificar o andamento do projeto. Com isso o gerente de projeto obteve a visão de todo projeto e aplicou melhorias. Também foi definido os possíveis DEF( Defeito, Erro e Falha) do projeto e testou o conhecimento dos profissionais em relação ao Programa de Qualidade 5s . Os resultados foram entregue a cada profissional e assim possibilitou-o e incentivou-o a fazer melhorias em seu projeto e sua funcionalidade.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3ª Fase – Construção

 

 

 

            Com objetivo de criar a estrutura necessária para o desenvolvimento se aplicou métricas de custo e esforço.  As métricas usadas foram COCOMO e Ponto de Função. A métrica COCOMO (COCOMO Básico - Constructive Cost Model – Boehm)  teve como objetivo estimar o custo:

 

 

E = Ab.KLOCBb = 3.0(3.3)1.12= 152 pm

 

D = Cb.EDb = 2.5(152)0.35 = 14,5 meses

 

Atualmente, um modelo de estimativa de custos de software se sai bem se puder estimar os custos de desenvolvimento de software de 20 % dos custos reais, em 70 % do tempo e dentro de seu próprio campo de ação (isto é, dentro das classes de projetos para as quais ele foi calibrado) .

         Ponto de função foi aplicada para análise de :

• Produtividade= KLOC/pessoa-mês ; FP/pessoa-mês

• Custo=$/LOC ; $/FP

 

 

         Com isso quantificamos Produtividade, Investimento , custo,  tempo e esforço dos profissionais por mês. Assim foi possível mensurar as alterações da estrutura para desenvolvimento do software CNS-V.

 

         Esta etapa também foi aplicadas as métricas para medir a eficiência do processo de desenvolvimento do Subsistema CNS-V e foi exibido o plano de correção dos tópicos deficientes, no qual foram metrificados. A avaliação foi feita através da ferramenta CASE  Borland Together Control Center.

         As métricas aplicadas foram: CC - Cyclomatic Complexity, DOIH - Depth Of Inheritance Hierarchy, NOCC - Number Of Child Classe, NOC - Number Of Classes, CR - Comment Ratio. 

           

 

Justificativa de uso das métricas citadas

  

CC - Cyclomatic Complexity :  Esta métrica tem como função quantificar o número de desvios (If, while, Case)  de um algoritmo.  Esta métrica demonstra as possibilidades de caminhos que o algoritmo fornece. Tendo essa visão se pode fazer um analise de onde pode conter defeitos que não se demonstraram como erro.

DOIH - Depth Of Inheritance Hierarchy: Esta métrica contas o baixo nível de hierarquia de herança de uma classe ou interface é declarada. Valores altos implicam que uma classe está bastante especializada.

 

NOCC - Number Of Child Classe: Contas o número de classes que herdam de uma classe particular, demonstra o número de classes na árvore de herança de uma classe particular. E interessante para se ter visão da reusabilidade do software.

 

CR - Comment Ratio: Quantifica  o número de comentários, um código bem comentado facilita a interoperabilidade dos programadores.

 

NOC - Number Of Classes:  Conta o número de classes e a descriminação de complexidade do código.

 

 

 

Plano para Correção dos Possíveis DEFeitos

 

 

          

 

Avaliar Exceções e Problemas

O primeiro passo é avaliar cada um dos problemas identificados na Avaliação de Status e na Lista de Problemas. A maioria dos projetos realiza uma "Reunião de Problemas" freqüente (geralmente semanal) com essa finalidade, com a participação do gerente de projeto, do arquiteto de software e dos chefes de equipe. 

Determinar as Ações Corretivas Apropriadas

Para cada problema/exceção, selecione a abordagem desejada para a resolução correspondente e determine os passos necessários para implementá-la.

Emitir Solicitações de Mudança e/ou Ordens de Trabalho

Após a definição da ação corretiva para cada problema ou exceção e das aprovações necessárias, o gerente de projeto documenta o trabalho envolvido e efetua Solicitações de Mudança e/ou Ordens de Trabalho para iniciar o trabalho. Em geral, ele pode retirar problemas da Lista de Problemas nessa etapa, pois o fechamento será rastreado de outra forma.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3ª/4ª Fase Construção/Transição

 

Foi criado e aplicado um plano de Teste. Os teste feito foram:

 

 Teste de Instalação: Instalar o sistema em várias máquinas diferentes, com configurações diferentes, para verificar toda a instalação, até eliminar todos os erros de instalação.

 

Software foi desenvolvido utilizando a linguagem JAVA que é portável e roda em qualquer plataforma. Essa característica da linguagem já foi testada e é garantida.

 Teste de Desempenho: Ferramenta: Rational Quantify

 

• Nível de desempenho do software; e
• Quantidade dos recursos utilizados.

 

Utilização do Quantify para análise de desempenho, facilitando a detecção de “gargalos” que impedem a melhor performance da aplicação.

 

Teste de Cobertura de Perfil:

Este teste tem por fim verificar se os requisitos de desempenho foram alcançados. Ele é implementado e executado para determinar o perfil dos comportamentos de desempenho do objetivo do teste e ajustá-los em função de condições como, por exemplo, configurações de hardware ou de carga de trabalho.

 

Cobertura do código, adequação e conformidade.

 Indicadores:

 Calls: número de chamadas a um determinado método:

• Methods Missed: número de vezes que um método não foi chamado;
• Methods Hit: métodos com maior índice de chamada; e

• % Methods Hit: índice, em percentual, das chamadas a determinado método.

 

Analise de Risco

            Criamos um artefato para mensurar o risco do projeto. Foi Usado a técnica FMEA (Failure Mode and Effect Analysis).

            A metodologia de Análise do Tipo e Efeito de Falha, conhecida como FMEA (do inglês Failure Mode and Effect Analysis), é uma ferramenta que busca, em princípio, evitar, por meio da análise das falhas potenciais e propostas de ações de melhoria, que ocorram falhas no projeto do produto ou do processo. Este é o objetivo básico desta técnica, ou seja, detectar falhas antes que se produza uma peça e/ou produto. Pode-se dizer que, com sua utilização, se está diminuindo as chances do produto ou processo falhar, ou seja, estamos buscando aumentar sua confiabilidade.

 

 

 

 

4ª Fase – Transição

 

Nesta fase foi consolidado a aplicação das Técnicas de Qualidade para desenvolvimento medição, verificação e validação de Protótipos de Sistemas CNS-V, visando melhorar sua eficiência, qualidade, confiabilidade e segurança, e foi apresentado o relatório final do projeto pela equipe de desenvolvimento e qualidade. Com base neste relatório será tiradas as conclusões de melhorias do software.

                À apresentação das técnicas foram feitas pelos seus desenvolvedores  assim demonstrando o conhecimento dos planos de qualidade.  Os processos serão auditados pelo Gerente de Projeto para se medir  o teor de Qualidade envolvido no Projeto.

  

 

 

 

 

 

 

 

 

 

 

 

 

 

III – CONCLUSÕES

 

 

                Este projeto junto com a matéria CE-230 Qualidade, Confiabilidade e Segurança de Softwares nos possibilitou ampliar a visão de desenvolvimento de software e qualidade em âmbito geral. Anteriormente nós éramos incapazes de quantificar a qualidade de um software e avaliávamos o software só por fatores empíricos. O que tornava nossa opinião falsa.

            Hoje, baseando-se no conhecimento adquirido, podemos qualificar um software que tenha qualidade e ainda mais podemos produzir um software com qualidade. E podemos suprimos a deficiência do mercado, pois existem pouquíssimos profissionais capacitados nessa área.

 

 RECOMENDAÇÕES

            Procure sempre melhorar as técnicas aqui explanadas, pois estas técnicas farão a diferença em qualquer projeto no qual se aplique.   Pois o objetivo  “ ter  o  CONTROLE do Software em todos os aspectos” é muito amplo e grandioso. E ter o controle é ter o poder.

           

 

 

 

 

 

 

IV – BIBLIOGRAFIA

- Rational Unified Process [RUP]

 

- Roteiro para as Listas de Exercícios 4-5-6 Aula16.1cCes63Ce23503a(RoteiroparaListEx4-5-6-PrjFinal)v3

 

-Documentação encontrada no endereço: http://www.comp.ita.br/~cunha/ensino/2003/aulas/ces32ce230/aulas.htm, referente a notas de aula da matéria CE-230 do ITA.

 

- www.bfpug.com.br – Brazilian Function Point Users Group – sobre Pontos de Função

 

- Engenharia de Software – Pressman Roger S., 5ª Ed, Editora Mc Graw Hill

- http://www.isdbrasil.com.br/

- http://www.cmcrossroads.com/bradapp/links/scm-links.html

- http://www.csis.ul.ie/Modules/CS5122/SCM.htm

- http://www.lnl.net/books/scm/resources.html

- Testes e Qualidade de Software,

 

 

Universidade do Minho , 7-Junho-2003

 

- www.cpqd.com.br, CPqD - Centro de Pesquisa e Desenvolvimento

em Telecomunicações Automação de Teste de Software: Incremento de Qualidade e Produtividade em Sistemas de Faturamento Telecom

Sindo Vasquez Dias