I – INTRODUÇÃO

1.1 – Motivação

Na atual conjuntura mundial, tecnologias têm se desenvolvido com grande velocidade. Deste modo, a busca por Qualidade de Software se torna cada vez maior.

O Setor de Tecnologia da Informação do Brasil vem, já há algum tempo, se preocupando com a questão de qualidade de software. Para definir os caminhos a serem seguidos nesta busca por uma melhor qualidade do software produzido internamente, empresas vem instituindo Programas para Melhoria da Qualidade do Processo de Software, através de pesquisas, contatos com fornecedores de soluções e ferramentas CASE.

Neste sentido, a qualidade passou a ser exigida em normas internacionais e fator decisivo para aqueles que pensam em exportar seus sistemas.

1.2 – Contexto

No Mundo Globalizado, o Software não é mais um objeto de individualização como outrora, agora os Softwares tem um mercado único: o Mundo.

A Obtenção de maiores níveis de Qualidade, Confiabilidade e Segurança nos processos e produtos de Engenharia de Software não é uma tarefa trivial. São vários os fatores necessários para atingir tais níveis.

Dentre esses fatores, utilizar I-CASE-E e obedecer a normas e padrões internacionais (ISO, CMM, etc) garante às empresas ligadas a Software um padrão aceitável de Qualidade, Confiabilidade e Segurança de seus produtos.

1.3 – Objetivo

1.3.1 - Enunciado do Problema

Medir quanto a Qualidade, Confiabilidade e Segurança, o Protótipo de Veículo Autônomo – PVA desenvolvido para o Laboratório Tecnológico da Fundação Casimiro Montenegro Filho no ITA, a fim de aumentar o nível de “maturidade” do código-fonte e reduzir o desperdício de recursos envolvidos.

1.3.2 – Enunciado da Alternativa de Solução Escolhida

Desenvolver, implementar e documentar o Sistema do Protótipo de Veiculo Autônomo – PVA, com Qualidade, Confiabilidade e Segurança.

1.3.3 – Intitulação

Sistema de Software com Qualidade, Confiabilidade e Segurança para o Protótipo de Veículo Autônomo – PVA.

1.4 – Redução do Escopo

O Projeto restringe-se ao Planejamento, Modelagem e a Aplicação de Métricas de Qualidade, Confiabilidade e Segurança de Software, através de Artefatos RUP e Ferramentas CASE, das Classes e dos 6 (seis) Casos de Uso selecionados como foco para extensão e análise de fluxos básicos e alternativos provindos da Disciplinas de Sistemas Embarcados de Tempo Real.

1.5 – Especificação de Requisitos

Elaborar Casos de Teste;
Planejar Testes de Software;
Estimar esforços necessários para o Projeto;
Modelar diagramas da UML focando Testes; e
Aplicar métricas de Qualidade, Confiabilidade e Segurança.

1.6 – Ordem da Apresentação do Projeto Final

Na Seção 1 “INTRODUÇÃO” apresenta-se a Motivação, o Contexto, os Enunciados do Problema e da Solução Escolhida, a Redução do Escopo e a Especificação de Requisitos deste Projeto Final.

Na Seção 2 “DESENVOLVIMENTO” descreve-se o desenvolvimento do Protótipo de Veículo Autônomo - PVA, por Fases do Processo Unificado da Rational – PUR (Rational Unified Process – RUP):

1a Fase – Iniciação (Inception);

2a Fase – Elaboração (Elaboration);

3a Fase – Construção (Construction); e

4a Fase – Transição(Transition).

Dentro da Seção 2:

Na 1ª parte será consolidada a linha base funcional apresentando o Plano de Testes, Casos Uso de Teste ou Estimativas de Esforços Por Pontos de Casos de Uso, para o Projeto PVA, elaborado pelos Alunos, enfocando a 1ª Fase - Iniciação (Inception) do Processo Unificado. Nesta Fase cada dois Alunos foram alocados na Disciplina para exercer um Papel, produzir um Artefato ou Documento, e utilizar a Ferramenta de Software Básico MS Word;

Na 2ª parte será consolidada a linha base alocada apresentando o Plano de Utilização de uma Ferramentas CASE de Qualidade de Software no Projeto PVA, para medir a Qualidade do Software, enfocando a 2ª e 3ª Fases – Elaboração (Elaboration) e Construção (Construction) do Processo Unificado:

1) Pelo menos 1 (um) Caso de Teste Estendido por Aluno;

2) Pelo menos 1 (um) Diagrama de Seqüência por Aluno (focando Testes);

3) Um Diagrama de Classe integrado com os Diagramas de Classes dos demais Alunos do Grupo, focando Testes;

4) A partir de Fragmentos de Códigos-Fonte gerados, cada aluno deverá utilizar 03 (três) Métricas para medir Qualidade, Confiabilidade e / ou Segurança do seu Software; e

5) Pelo menos 1 (uma) Análise de Sensitividade de Software e e 1 (uma) Análise de Traçabilidade de Requisitos.

Na 3ª parte será consolidada a linha base de produto.

Finalmente, na Seção 3 “CONCLUSÕES e RECOMENDAÇÕES”, são sintetizadas as principais conclusões, recomendações e sugestões para aperfeiçoamento deste Protótipo e para a melhoria dessa matéria.

II – DESENVOLVIMENTO

2.1 – Linha Base (Base Line) Funcional

Foram utilizados os artefatos para a Fase de Iniciação do RUP. Os artefatos são mostrados abaixo.

2.1.1 – Plano de Teste

Plano de Teste

2.1.2 – Casos de Teste

Casos de Teste

2.1.3 – Estimativa de Esforços por Pontos de Casos de Uso

O Método de Pontos de Caso de Uso - PCU baseia-se no Modelo de Casos de Uso, que é muito utilizado para identificar e documentar os Requisitos do Software nos termos dos Usuários. O Método de PCU representa uma maneira mais completa e articulada do que os demais métodos existentes, possibilitando Estimativas de Tamanhos e Esforços de Desenvolvimento de Software, logo na Fase Iniciação (Inception) de um Projeto de Software; e é Fácil de Usar.

Abaixo, é mostrado um gráfico comparando Estimativas de Esforços por Pontos de Casos de Uso com a Análise de Pontos de Função, que é a métrica mais utilizada:

Utilizamos esta métrica para medir o nosso sistema, conforme pode ser observado no documento abaixo:

Estimativa de Esforços por Pontos de Casos de Uso

2.2 – Linha Base (Base Line) Alocada

Enfocando os aspectos de Qualidade, Confiabilidade e Segurança, os alunos do grupo desenvolveram cada um dos artefatos mostrados abaixo e posteriormente fizeram sua consolidação. Cada aluno ficou responsável por um caso de uso específico. O caso de uso que será abordado neste documento é o caso de uso Entregar Pacote.

2.2.1 – Caso de Teste Estendido – Entregar Pacote

A finalidade do Caso de Teste Estendido é identificar e comunicar formalmente as condições específicas detalhadas que serão validadas para permitir a avaliação do Caso de Uso Entregar Pacote.

O modelo de documento Caso de Teste concentra-se nas Fases do RUP de Iniciação, Elaboração, Construção e Transição aplicadas ao Projeto PVA – Protótipo de Veículo Autônomo.

Este Caso de Teste Estendido descreve os Cenários de Testes do Caso de Uso Entregar Pacote, do sistema do Protótipo de Veículo Autônomo – PVA.

A partir do Caso de Uso Entregar Pacote foram encontrados os seguintes cenários:

Cenário 1 – A entrega do pacote ao PVT é bem sucedida.	Fluxo Básico
Cenário 2 – Não encontra o PVT.	Fluxo Básico	Fluxo Alternativo 1 – Não encontra o PVT.
Cenário 3 – O PVT não tem espaço suficiente para receber a caixa	Fluxo Básico	Fluxo Alternativo 2 – Não há espaço no PVT para guardar a caixa.
Cenário 4 – MCM encontra-se Off-Line.	Fluxo Básico	Fluxo Alternativo 3 – MCM encontra-se Off-Line.

A partir dos Cenários anteriores, foram encontrados os seguintes Casos de Teste:

ID de Caso de Teste	Cenário	Coordenada	Espaço no PVT	Informar ao MCM	Resultado Esperado
CT 1	Cenário 1 – A entrega do pacote ao PVT é bem sucedida e é feita a confirmação de entrega ao MCM.	V	V	V	Entrega do pacote ao PVT e confirmação desta entrega para o MCM.
CT 2	Cenário 2 – O PVT não se encontra no local de destino.	F	V	V	Retorna mensagem de erro, recalcula nova rota.
CT 3	Cenário 3 – O PVT não tem espaço para receber a caixa	V	F	V	Retorna mensagem de erro, fim do Caso de Uso.
CT 4	Cenário 4 – MCM encontra-se Off-Line (desligado).	V	V	F	Se possível continua a missão e tenta a cada 5 segundos informar novamente.

Deve ser observado se o PVA continua com a missão e se a cada 5 segundos tenta novamente informar o resultado da missão para o MCM.

Pontos de Controle

N/A – Não Aplicável.

Resultados Esperados

Novas tentativas de envio do resultado da missão.

Pós-condições

O PVA continua com a missão.

Mais detalhes sobre o Caso de Teste Estendido Entregar Pacote podem ser observados no anexo Caso de Teste Estendido.

2.2.2 – Diagrama de Seqüência – Entregar Pacote

A seguir é mostrado o diagrama de seqüência para o Caso de Teste Estendido Entregar Pacote.

2.2.3 – Diagrama de Classe Integrado

Abaixo, é mostrado o diagrama de classes integrado com os outros alunos do grupo. O Caso de Uso Entregar Pacote possui a classe Pacote.

2.2.4 – Métricas de Qualidade de Software

Foi utilizado um fragmento de código gerado no projeto TRIPHIBIUS (Veículos Experimentais do Tipo Carro Anfíbio Voador), realizado na disciplina CE-235 do ano passado, pois a aluna não estava cursando a disciplina CE-235 neste semestre. Veja o código-fonte.

Foi utilizada a ferramenta Borland Together for JBuilder:

Aí então, foram escolhidas as métricas que mais se aplicam ao nosso sistema:

No caso, escolhemos as seguintes métricas:

NORM - Number Of Remote Methods

Processa todos os métodos e construtores e conta o número de vários métodos remotos chamados.

WMPC1 - Weighted Methods Per Class 1

Mostra a soma da complexidade dos métodos por classe, onde o método é ponderado pela sua Complexidade Ciclomática. O número de métodos e a complexidade dos métodos envolvidos é o que indica quanto tempo e esforço será requerido para o desenvolvimento e manutenibilidade da Classe.

WMPC2 - Weighted Methods Per Class 2

Mostra a Complexidade de uma Classe, assumindo que a classe que possui mais métodos é a mais complexa, e que o método com mais parâmetros é analogamente mais complexo.

LOC - Lines Of Code

Tradicional medida de tamanho. Utilizado para restrição para obtenção do Custo final do Software.

Utilizamos o Kiviat Graph para fazer a avaliação das métricas:

2.2.5 – Análise de Sensitividade de Software

Percebemos pelo resultado no item anterior, que existem algumas normas fora do padrão de Qualidade de Software. Fazendo algumas alterações no código (alteramos o número de chamadas a métodos) e desprezando a métrica LOC, obtivemos o seguinte resultado mostrado a seguir:

Que indica que todos os parâmetros medidos pelas métricas escolhidas estão dentro do esperado pelas configurações.

2.2.6 – Métricas de Confiabilidade de Software

Métricas de Confiabilidade de Software em geral são categorizadas em dois tipos principais: aquelas que são projetadas para contabilizarem os erros durante os testes e aquelas que consideram como medida de confiabilidade o intervalo de tempo decorrido entre a ocorrência de dois erros.

Dentre as métricas de confiabilidade, podemos citar:

ü Mean Time Between Failures ou MTBF - É usada para relatar o tempo médio entre falhas, que indica na média o período em que um sistema é utilizável;

ü Mean Time To Repair ou MTTR – É o tempo médio para reparos, que quantifica o tempo necessário para recuperar o sistema de uma falha;

ü Mean Time Between Service Outage ou MTBSO - taxas de erros que podem ser taxas de perda de pacotes e quadros;

ü Uptime e Downtime – No Linux, o comando uptime é utilizado, inicialmente, para mostrar a quanto tempo o sistema está em operação ininterruptamente. Além disso, também mostra mais algumas informações interessantes: número de usuários logados no momento, e as médias de cargas para os últimos 1, 5 e 15 minutos. Um exemplo de saída do uptime é:

Este exemplo nos diz que a máquina está em operação há 23 dias, oito horas e 45 minutos. Existem 9 usuários logados no sistema e as médias de carga do sistema nos últimos 1, 5 e 15 minutos são 0,17, 0,05 e 0,01, respectivamente.

2.2.7 – Métricas de Segurança de Software

Abaixo, segue uma tabela de métricas de segurança que podem ser aplicadas ao projeto PVA quando este estiver em pleno funcionamento:

2.2.8 – Análise de Traçabilidade de Requisitos

Os requisitos foram alcançados dentro do padrão, seguindo a ordem de construção dos papéis: primeiramente foi construída a linha base funcional apresentando o Plano de Testes, Casos Uso de Teste ou Estimativas de Esforços Por Pontos de Casos de Uso. Estes papéis foram efetuados a partir dos Casos construídos na disciplina CE-235. Depois foi efetuada a linha base alocada, e a partir dos Casos de Teste, foram montados os Casos de Teste Estendidos e os respectivos diagramas.

2.2 – Linha Base (Base Line) de Produto

Foram consolidados todos os papéis produzidos durante as fases do projeto. Estes papéis foram mostrados durante a apresentação conclusiva sobre o nosso sistema. O produto final foi satisfatório e cumpriu os requisitos de software preestabelecidos.