Apresentação do Projeto Final do Sistema CNS-T. Sistema CNS-T Sub-sistema COMU-TRI: –Wladimir, Lúcio, Brito, Silvestri e Edimar Sub-sistema MAPA-TRI:

Slides:



Advertisements
Apresentações semelhantes
Metodologia de testes Nome: Gustavo G. Quintão
Advertisements

Qualidade de Software Aula 4
Requisitos de Software
Sistemas distribuídos Metas de Projeto Prof. Diovani Milhorim
Adélia Barros Testes de Software Adélia Barros
Qualidade de Produto de Software
UNIVERSIDADE ESTADUAL DE MATO GROSSO DO SUL SISTEMAS DE INFORMAÇÃO ENGENHARIA DE SOFTWARE Métricas de Software Prof.ª Adriana dos Santos Caparróz Carvalho.
Confiança.
ISO/IEC – 6 Avaliação do Produto – Módulos de Avaliação
Centrado na arquitetura
Walter de Abreu Cybis Outubro, 2003
Administração de Sistemas de Informação II
SISTEMA DA INFORMAÇÃO GEOGRÁFICA
O processo de coletar os requisitos (escopo do cliente)
Análise e Projeto de Sistemas
ESTRUTURA DE COMUNICAÇÃO DE DADOS
TIPOS DE TESTES APLICÁVEIS E NÃO APLICÁVEIS AO PROJETO
Aspectos Avançados em Engenharia de Software Aula 3 Fernanda Campos
Gabriel Silva Bornia Prof. Dr. Roberto Tom Price Orientador
Gerencia de Projeto OO Aspectos Avançados em Engenharia de Software Aula 5 Fernanda Campos DCC/UFJF.
TSDD Teste de segurança durante o desenvolvimento.
Visão Geral do Desenvolvimento de Sistemas e Papéis no Desenvolvimento de Software Marcely Dias
Pontifícia Universidade Católica de Campinas
RUPinho Qualidade de Software
Estudo de Caso: Técnicas de Teste como parte do Ciclo de Desenvolvimento de Software Aline Pacheco Patric Ribeiro Diego Kreutz.
Orientações sobre usabilidade
Planejamento e Gerenciamento de Projetos
Visão Geral PRO.NET.
Cap 4 – Métricas do Processo e Projeto de Software
Projeto MONITORAMA CMD-TD – Automação para a Tomada de Decisão
Fase de Elaboração: Fluxo de Requisitos
Qualidade de Produto de Software
Sistemas Distribuídos
Arquitetura do Software
PFC Projeto Final de Curso
ANÁLISE E DESENVOLVIMENTO
Prof. Silvestri – todos os direitos reservados SISTEMAS DISTRIBUIDOS Aula 5 Eduardo Silvestri
Qualidade de Software Aula 4
1 2º Semestre de 2006 CSC V-CTR USC CTR – Vinícius USC POT - Caio USC COMB - Débora Prof. Cunha Prof. Vieira Dias Prof. Márcio Programa de Pós-Graduação.
O que é? É o processo de investigação técnica com intuito de identificar a qualidade, a segurança e a exatidão do software desenvolvido. A validação do.
Redes Sociais Colaborativas Patrícia Ramos | 22/05/2006.
Gestão de defeitos.
GPS Sistema de Posicionamento Global
Laboratório de Programação
Automação de Testes de Software
Capítulo 10 – Qualidade de Produtos de Software Escrito por: Renata Araújo Vírginia Chalegre Apresentado por: Cleice.
Fase de Concepção Levantamento de Requisitos, Organização de Requisitos, Planejamento dos Ciclos Iterativos.
Gestão de Projetos de Software
Equipe ADA Recife, 2003 Projeto de Desenvolvimento de Software Profs. Hermano Perrelli e Jacques Robin MARCO ZERO Equipe ADA Francisco De A. M. Valadares.
Base de Conhecimento em Teste de Software Gestão de Defeitos
CONECTIVIDADE Prof.: Alessandro V. Soares Ferreira
ITA – Instituto Tecnológico de Aeronáutica
Sistema de Monitoramento de Rotas Documento de Visão Versão /4/2015 Versão
IEEE Melhores Práticas para Descrições de Projeto de Software (DPS)
CSC E-CNS CE-235 Sistemas Embarcados de Tempo Real 2° Semestre de 2006 Componente de Software de Computador de Comunicação, Navegação, Vigilância CSC E-CNS.
Introdução à modelagem orientada a objetos
Instituto Tecnológico de Aeronáutica Divisão: Engenharia Eletrônica e Computação CSC - PDTL Disciplina: CE 230 – Qualidade, Confiabilidade e Segurança.
Processo e Qualidade.
Prof. Sidney Galeote. 2 www. prasabermais. com  Visão Geral sobre a dimensão de qualidade “performance”  Custo da qualidade  Como a performance deve.
Análise e Projeto de Sistemas Análise e Projeto de Sistemas Aula 2 Professor: Italo Rodrigues Castro.
Engenharia de Requisitos Prof. Fábio Botelho, MSc Redes e Sistemas Distribuídos Recife, Agosto de 2012.
APSI II Análise e Projeto de Sistemas de Banco de Dados II.
Engenharia de Software com o RUP - Workflow de Requisitos
Um Sistema de Gerenciamento de Emissoras de Televisão.
TÉCNICAS DE ESTIMATIVAS
QUALIDADE DE SOFTWARE Prof. Carlos Augusto da Costa Carvalho.
PROJETO SPICE ISO Integrantes: Erickson Balzaneli
1 Projeto Piloto Conclusão em Agenda Projeto Piloto –Descrição –Execução da aplicação –Implementação de requisitos funcionais e não- funcionais.
1 Estimativa, Teste e Inspeção de Software Gerência de Projetos: Estimativa de Software Marcos Camada
Processos de Software Ludimila Monjardim Casagrande 1º Semestre Desenvolvimento e Qualidade.
Transcrição da apresentação:

Apresentação do Projeto Final do Sistema CNS-T

Sistema CNS-T Sub-sistema COMU-TRI: –Wladimir, Lúcio, Brito, Silvestri e Edimar Sub-sistema MAPA-TRI: –Juliana e Luiz Claudius Sub-sistema NAVE-TRI: –Daniela, Guaragna e Leonardo Sub-sistema ROTA-TRI: –Rafael, Alexandre e Pablo

Roteiro Introdução Requisitos Artefatos Ferramentas CASE Estimativas de Recursos Necessários Métricas Aplicadas no Código Aplicação da Técnica FTA Conclusão

Introdução Motivação: –Veículos do tipo carro-anfíbio voador podem realizar missões tripuladas e não-tripuladas –Necessitam de controle, direcionamento, sistemas de mapeamento, comunicação e navegação –Precisa-se de uma interface com o piloto / estação de controle –É necessário informar a localização do veículo na região –É preciso estabelecer comunicação do veículo com a estação e demais veículos

Introdução Contexto: –Projeto TRIVIG é composto por: Veículo TRIPHIBIUS e estação VIGILANTE –TRIPHIBIUS necessita de um sistema responsável por: navegação, mapeamento, comunicação e roteamento –A navegação trata de formas de determinar a localização do veículo através da utilização de GPS e de armazenar e recuperar planos de vôo –O mapeamento provê mapas ao piloto, a fim de facilitar a definição de sua trajetória –Sistema de comunicação robusto e eficiente, onde o contato com a estação de controle VIGILANTE, bem como com qualquer outro veículo

Introdução Enunciado do Problema: Fornecer, ainda este semestre, ao veículo Triphibius, um sistema que permita sua navegação, sua comunicação e seu mapeamento e que esteja integrado aos outros sistemas do Triphibius e da estação Vigilante, a fim de possibilitar que as missões do veículo sejam executadas da melhor forma possível, aumentando sua eficácia e eficiência.

Introdução Enunciado da Solução: Desenvolver, ainda este semestre, um protótipo de sistema de software embarcado para navegação, comunicação e mapeamento do veículo Triphibius e que esteja integrado aos outros sistemas do veículo e da estação Vigilante, a fim de possibilitar que as missões do veículo sejam executadas da melhor forma possível, aumentando sua eficácia e eficiência.

Requisitos O protótipo do Sistema CNS-TRI deverá ser capaz de propiciar: –Informação precisa da localização do veículo com a utilização de GPS –Inserção e acesso a planos de vôo cadastrados e requisitados –Visualização de mapas –Utilização de freqüências comumente utilizadas no link via rádio –Recebimento de pedidos de ajuda pelo canal de emergência e localização de veículos em pane –Informar melhor rota aérea, marítima e terrestre

Artefatos Lista de Riscos: – Falha de comunicação com o satélite do GPS –Atraso no envio da coordenada pedida –Dano na mídia armazenadora de mapas –Falha de comunicação com a torre –Redução da equipe de desenvolvimento alocada (caso do Sub-sistema MAPA-TRI) –Aumento do escopo do projeto (inclusão do Sub-sistema ROTA-TRI)

Artefatos Plano de Métricas: –Tempo de carregamento do mapa –Tempo de resposta das coordenadas –Precisão da rota –Falhas no recebimento de alertas de pane por período

Artefatos Casos de Teste: Exemplo do sub-sistema COMU-TRI –Teste de Funcionamento Um usuário utilizando o sistema de comunicação Triphibius consegue se comunicar com outro usuário utilizando um outro Triphibius. –Teste de Interface do Usuário Todas as funcionalidades fornecidas pelo sistema de comunicação ao usuário contém formas de uso. –Determinação do Perfil de Desempenho O tempo mínimo da comunicação entre veículo Triphibius e estação Vigilante estão sendo seguidos. –Teste de Carga A comunicação entre estação Vigilante e 5 veículos Triphibius de forma simultânea mantém o tempo limite máximo de espera na comunicação.

Artefatos Casos de Teste: –Teste de Stress Efetuar uma comunicação simultânea entre veículos Triphibius e estação Vigilante para determinar o número máximo de veículos possíveis se comunicando dentro do tempo limite máximo de espera na comunicação especificado. –Teste de Segurança e de Controle de Acesso Toda comunicação entre o veículo Triphibius e a estação vigilantes estão sendo feitas encriptadas utilizando chaves aleatórias e tecnologia PKI.

Ferramentas CASE Ferramentas estudadas: –Rational Requisite Pro: Gestão de Requisitos –Rational Quantify:identificar bottle neck –Rational Purify: identificar vazamento de memória –Borland Caliber: Gestão de Requisitos –Borland Together: modelagem e aplicação de testes

Estimativas de Recursos Necessários Ponto de Função: –Utilizado para se medir o tamanho de um Software pela quantificação de sua funcionalidade externa –Usado como prova de conceito –Y = número de defeitos esperados para o projeto –COMU-TRI: Y = 95 –MAPA-TRI: Y = 88 –NAVE-TRI: Y = 719 –ROTA-TRI: Y = 125

Estimativas de Recursos Necessários COCOMO (Cost Constructive Model): –Computa o esforço e custo de desenvolvimento de software como uma função de tamanho de programa expresso em linhas de código estimadas –Usado como prova de conceito –Y = número de defeitos esperados para o projeto –COMU-TRI: 4 pessoas / 4 meses –MAPA-TRI: 5 pessoas / 4 meses –NAVE-TRI: 5 pessoas / 4 meses –ROTA-TRI: 4 pessoas / 4 meses

Métricas Aplicadas no Código NAVE-TRI: –CR (Comments Ratio): É a razão de comentários por linha de código –avEIAV (Explicity Analize all Variables): Conta o número de variáveis declaradas e não inicializadas –avULVFP (Unused Local Variables and Formal Parameters): Conta o número de variáveis que não são utilizadas.

Métricas Aplicadas no Código NAVE-TRI:

Métricas Aplicadas no Código MAPA-TRI: –LOC (Lines of Code): número de linhas de código de cada classe. –NOA (Number of Atributes): número de atributos de cada classe. –PPrivM (Percentage of Private Members): percentagem de elementos, dentro de cada classe, que são privados, ou seja, que só podem ser acessados pela própria classe

Métricas Aplicadas no Código MAPA-TRI:

Aplicação da Técnica FTA Fault Tree Analysis Postula-se que o sistema falhou de um certo modo e tenta-se determinar que formas de componentes do sistema contribuíram para a ocorrência dessa falha

Aplicação da Técnica FTA CNS-T FALHA NA ORIENTAÇÃO DO VEÍCULO NAVE FALHA NO FORNECIMENTO DAS COORDENADAS COMU FALHA NO RECEBIMENTO DE COORDENADAS DA VIGILANTE MAPA MAPA FORNECIDO INCORRETO ROTA FALHA NO CÁLCULO DA ROTA

Aplicação da Técnica FTA Probabilidades: NAVE = 0,02 MAPA = 0,01 COMU = 0,01 ROTA = 0,02 CNS-T = 0,02+0,01+0,01+0,02=0,06

Conclusão Houve o entendimento maior sobre métricas e sobre o desenvolvimento de um plano de métricas para um projeto de software Aprendemos a utilizar ferramentas que representam o estado da arte para medir Qualidade, Confiabilidade e Segurança de Software Estudamos Ponto de Função e COCOMO a fim de estimar os recursos necessários para os sub-sistema Usamos a ferramenta Together no âmbito de aplicação de métricas no código que implementa o sistema Aprendemos a técnica FTA