INSTITUTO TECNOLÓGICO DE AERONÁUTICA
CE‐230 QUALIDADE, CONFIABILIDADE E
SEGURANÇA (SAFETY) DE SOFTWARE
RELÁTORIO FINAL
PROJETO SETRAIF – MODULO DCF
CE‐230
Valdir Guerra
AlunoProfessor Dr. Adílson Marques
Cunha
Fundação Getulio Vargas
2
1.
INTRODUÇÃO 1.1. TituloRelato Padronizado da disciplina CE230 Projeto SETRAIF Sub produto DCF – Relátorio Final. 1.2. Motivação
Desenvolver habilidades para inferir qualidade, confiabilidade e segurança em dispositivos de software embarcados de tempo real, métodos ágeis para realizar entregas mais rápidas e confiáveis em meus trabalhos acadêmicos e em projetos futuros.
1.3. Contexto
O projeto SETRAIF contextualiza o desenvolvimento de um protótipo do sistema de
repressão a acessos indevidos e fraudes o qual será utilizado inicialmente nos laboratório do instituto tecnológico da aeronáutica com fins acadêmicos para pratica das principais
disciplinas de desenvolvimento, teste, qualidade, confiabilidade e segurança de software embarcado de tempo real assim como a integração das disciplinas utilizando métodos e ferramentas case de engenharia de software auxiliadas por computador.
1.4. Objetivo do Protótipo
Consolidar a aplicação dos principais conhecimentos teóricos adquiridos nas Disciplinas CES-63, CE-235, CE-230 e CE-237, durante o processo de desenvolvimento do Protótipo do Sistema Embarcado de Tempo Real para Repressão a Acessos Indevidos e Fraudes - SETRAIF, visando melhorar a eficiência e reduzir o desperdício de recursos envolvidos.
1.5. Redução do Escopo
O Projeto SETRAIF foi dividido em 4 módulos (DMV, DCN, DCA, DCF). O Modulo em questão que será descrito abaixo é o do DCF (Dispositivo de controle de fraudes). Os outros módulos podem ser visualizados nos outros relatórios finais publicados na paginas do projeto. O Modulo DCF foi analisado junto com o PO (Product Owner). O objetivo do DCF é analisar a transação enviada pelo DCA e retornar um resultado de não fraude ou fraude indicando um percentual com a probabilidade de fraude.
O Modulo DCF ainda apresenta mecanismos de analise da disponibilidade dos serviços dependentes evitando assim a queda e o processamento de transações sem um claro resultado analisado, assim como dados e informações para futura analise.
1.6. Especificação de Requisito
A Especificação de Requisito foi elaborada utilizando “Users Storys” e teve as seguintes definições
Como DCF eu tenho que compor uma arquitetura de desenvolvimento dirigido a modelos MDA, a fim de compor o software embarcado de tempo real SETRAIF fornecendo o serviço de analise retornando fraude ou não fraude para o modulo do DCA.
Como DCF eu tenho que dispor de uma infraestrutura de serviços mínimos como banco de dados e servidores na nuvem a fim de armazenar dados para futura análise.
Como DCF e tenho que detectar a fraudes considerando o padrão de consumo, a localização geográfica e o dispositivo sendo utilizando, a fim de gerar um resultado apontando a transação como sendo uma fraude ou sendo uma transação legitimam.
3
Como DCF eu tenho que localizar classificar e registrar as transações e resultado de fraude para futuras análises e investigação de causas prováveis.
Como DCF eu tenho que aperfeiçoar o sistema de detecção de fraudes para eliminar o desperdício de tempo e financeiro em fraudes com transações de compra e venda por cartão de credito através do celular.
1.7. Ordem Apresentação do Relatório do Projeto Final da Disciplina
A Seção 1 apresenta os objetivos do projeto SETRAIF, assim como o ganho de conhecimento do time de desenvolvimento trazendo um solução inovadora para um problema antigo. A Seção 2 ...
2.
DESENVOLVIMENTO2.1. DESCRIÇÃO DO PROJETO SETRAIF
O projeto SETRAIF contextualiza o desenvolvimento de um protótipo do sistema de repressão a acessos indevidos e fraudes. O Sistema foi elaborado utilizando MDA (“Model Driven Arquitecture” unindo diversas matérias permitindo assim o desenvolvimento de um solução de hardware e software integradas.
A solução consiste em propiciar uma venda através de um dispositivo móvel substituindo o tradicional modelo de cartão de credito.
METODO TRADICIONAL NOVO METODO
O Sistema apresenta ainda dispositivos de segurança que trabalham para diminuir e/ou eliminar os atuais problemas com fraudes
4
Arquitetura:
Diagrama de Estados:
PRODUCT BACKLOG
Como DCA/Servidor de Aplicação Web eu gostaria de um Arduino com acesso a internet para que eu possa realizar a troca de informações através da internet .
5
eu possa validar ou não uma transação .
Como desenvolvedor eu gostaria de um banco de dados modelado para suportar e consultar as informações da solução
Como um desenvolvedor eu gostaria de um ambiente de desenvolvimento para executar a implementação da solução .
Como um desenvolvedor eu gostaria de um servidor configurado para implantar minha solução.
Como DCA eu gostaria de validar se a localização de determinada transação indica se é uma possível fraude para que eu possa liberar ou não uma transação eletrônica de fundos
Como DCA eu gostaria de validar se o padrão de consumo de determinada transação indica se é uma possível fraude para que eu possa liberar ou não uma transação eletrônica de fundos.
Como DCA eu gostaria de validar se o dispositivo utilizado em determinada transação indica se é uma possível fraude para que eu possa liberar ou não uma transação eletrônica de fundos.
Como analista de fraudes eu gostaria de saber o endereço de onde partiu transação suspeita para que eu possa avaliar se o local da transação tem histórico de crimes.
Como analista de fraudes eu gostaria de obter um relatório de possíveis fraudes identificadas para que eu possa verificar manualmente padrões de transações fraudulentas.
Como analista de fraudes eu gostaria de realizar buscas nas fraudes detectadas para que eu possa obter detalhes de uma possível fraude. Como DCA eu gostaria de obter com agilidade se determinada transação é 1 uma possível fraude para que eu possa ser responsivo em tempo aceitável para o comércio.
Para construir o projeto SETRAIF foi utilizado as melhores praticas da metodologia ágil SCRUM. O Projeto foi dividido em 2 (duas) Sprints, abaixo segue a minha participação individual em cada Sprint:
Sprint 1
Minha Participação
Elaborou um modelo no Rational Rose Real Time da concepção das capsulas do DCA e DCF com destaque para o processamento do recebimento de um transação do DCA, analise da mesma em 3 níveis diferentes pelo DCF e devolução para DCA com resultado de fraude ou não fraude.
Elaborei o Harness Test do modelo citado acima, provando através de um diagrama de estrutura e um diagrama sequencia o happy path da interação entre o DCA e o DCF considerando todas as possibilidade de resultado.
Analisei os requisitos em formato de “User Story” e ajudei na concepção de adaptações que permitiram melhorar o entendimento do time na construção de um modelo
Participei de interações por e-mail com o time de desenvolvimento colaborando com a troca de informações para construção do software.
6
Elaborei a apresentação do resultado da Sprint 1 para apresentação da ListEx 3 e ajudeis na concepção.
Participei de reuniões por Skype para realizar inspeções e adaptações para melhorar a concepção da entregas dos manual de qualidade, e resultados do RRRT
Sprint 2
Minha Participação
Participei de reuniões presenciais para colaborar com a integração do DCF com DCA assim como a na concepção da integração de todos os outros 3 módulos, sempre se preocupando com o conceito de qualidade, segurança e confiabilidade.
Colaborei na participação da construção do script de alinhamento das entregas da Sprint 2 Ajudeis na definição das adaptações que o DCF deveria sofrer para gerar um resultado mais eficiente no que tange a analise de fraudes.
Participei das reuniões colaborando para a construção do segundo harness test da entrega da Sprint 2
Elaborei a apresentação do resultado da Sprint 2 para apresentação na reunião final.
Dei ideias para o modelo embarcado do DCF junto ao SCRUM máster 2.2. SÍNTESE DAS LISTEX 3
2.2.1. HARNESS TEST
O Objetivo é simular a execução do modelo DCF no Rational Rose Real Time
implementando um teste RQA - HARNESS com o proposito de aferir qualidade, confiabilidade e segurança entre a interação do DCA com o DCF
Para viabilizar o teste foi criando um projeto no ambiente do RRRT com duas capsulas representando o DCA (Dispositivo de controle de Acesso) e o DCF (Dispositivo de controle de Fraudes)
7
As capsulas DCA e DCF foi conectada utilizando um protocolo denominado como token, que tem a responsabilidade de transportar a transação.
Estrutura da capsula DCA tem o objetivo de receber uma nova transação, realizar a autenticação e enviar a transação para o DCF
Estrutura da capsula DCF tem o objetivo de receber a transação do DCA e validar a
transação com o padrão de consumo do usuário, depois validar a transação utilizando analises GEO Referenciadas e finalmente devolve para a transação para DCA com status de aprovada ou reprovada com todas interações devidamente logadas
8
Demonstração Pratica da Execução da Capsula SETRAIF com os subprodutos DCA e DCF Interagindo:
9
Analise do Trace
10
11
HARNESS TEST DIAGRAMA DE COLABORAÇÃO
HARNESS TEST DIAGRAMA DE SEQUENCIA HAPPY TEST
12
13
2.3. ANALISE DE SENSIBILIDADE Abaixo segue os objetivos dessa analise
• Qualidade
Desenvolver um produto vislumbrado na Visão do Produto, atendendo assim as expectativas do cliente.
• Confiabilidade
Desenvolver um software capaz de cumprir seus requisitos funcionais de forma alheia a falhas.
• Segurança
Garantir que o software execute suas funções, sem acarretar em riscos inaceitáveis para todo o sistema.
Dada às definições, foram então realizadas algumas interações por parte da equipe de qualidade, confiabilidade e segurança, a fim de garantir que os requisitos essências fossem garantidos.
INTERAÇÃO 1 - QUALIDADE Primeira pergunta
O P.O tem visibilidade do andamento da Sprint, mesmo com um time decentralizado? Resposta: Sim, para prover visibilidade do andamento da Sprint foi utilizada uma
ferramenta online, a fim de transparecer o andamento das atividades em tempo real para o P.O.
Segunda Pergunta
De que forma o time de desenvolvimento planejou as releases para desenvolver entregáveis que satisfaça de forma incremental a expectativa do P.O?
Resposta: Por se tratar de um ambiente sem material inicial como a VM com toda a suíte de ferramentas CASE do IBM Rose Rational Real Time, foi preciso planejar não somente a construção da aplicação, mas também o ambiente de desenvolvimento e da aplicação. Foi então dividido em 2 principais entregas, sendo elas a de desenvolvimento do ambiente de desenvolvimento e servidor e outra contemplando as regras e necessidades de negócio. Planejamento respaldado pelo cliente.
INTERAÇÃO 2 - CONFIABILIDADE Primeira Pergunta
Como pretendem minimizar ou gerenciar a introdução de bugs no sistema?
Resposta: Todas as partes críticas do sistema haverá testes unitários, a fim de assegurar que qualquer modificação no software seja feita de forma segura, mantendo uma boa cobertura de áreas compreendidas como alheias a bugs.
Segunda Pergunta
Como garantir que novos requisitos não tenham impactos profundos no prazo, garantindo assim, a agilidade da equipe em absorver itens com valores de negócios latentes?
Resposta: Além das cerimônias para inspeção e adaptação do processo/produto, também será construída uma arquitetura evolutiva, que visa o mínimo esforço necessário para
14
implementar uma feature visando a melhor relação entre custo beneficio da entrega do produto x escalabilidade da aplicação.
INTERAÇÃO 3 - SEGURANÇA Primeira Pergunta
Quais as medidas tomadas para garantir a disponibilidade no servidor de aplicação web? Resposta: A aplicação esta hospedada no ambiente do google, que gerencia e se responsabiliza por esse ambiente, atualmente o Google App Engine garante 99,95% de disponilidade.
Segunda Pergunta
Como serão tratadas exceções?
Resposta: Caso haja alguma falha, a transação será aprovada se o valor for inferior ao valor acordado com o cliente.
GRÁFICO KIVIAT
2.4. O PLANO DE GARANTIA
O Plano de Garantia do DCF foi elaborado para fornecer uma visão única sobre a qualidade para o projeto e assim, garantir que o software gerado estará de acordo com as normas e requisitos do cliente.
O plano foi elaborado com aderência as praticas de um ciclo de desenvolvimento iterativo e incremental de um protótipo acadêmico, que garanta que os requisitos do projeto e do cliente estejam sendo atendidos em sua totalidade e de forma contínua, produzindo resultados de valor aos interessados.
O Plano não contempla critérios de validação do produto, a validação do produto backlog, definição de pontos por estórias e definição de ponto.
Conformidade será validada considerando o principal produto a ser auditado. Verificando e validando o incremento de software potencialmente empregável e validado pelo Product Owner.
15
Foi utilizado como referencia a Norma: ABNT NBR ISO/IEC 9126-1:2003 - Qualidade de produto / Parte 1: Modelo de qualidade
2.5. CONSIDERAÇÃO SOBRE AFERIÇÃO DE QUALIDADE, CONFIABILIDADE E SEGURANÇA DE SOFTWARE.
Quando se considera que qualidade é conformidade com requisito, confiabilidade é qualidade no tempo e segurança é a avaliação do fator humano, interface homem maquina e analise dos fatores críticos, pode-se concluir que esses 3 pilares geram resultados capazes de eliminar prejuízos, reduzir desperdícios de tempo e garantir produtos de software realmente diferenciados.
O ponto aqui é como construir produtos de software que realmente tenham na sua concepção os 3 pilares.
Dessa maneira, a Lei natural de um software construído com qualidade, confiabilidade e segurança se aplica principalmente a forma de pensar das pessoas que interagem com o projeto.
Uma boa metodologia pode ajudar no incremento de qualidade, porem a instalação de um cultura de qualidade, confiabilidade e segurança é a única forma de realmente garantir produtos de software que sejam qualificados, confiáveis e seguros.
3.
PRINCIPAIS CONCLUSÕESCom a execução do projeto SETRAIF - foi possível aprimorar o conhecimento das técnicas de aferição de qualidade confiabilidade e segurança em sistemas embarcados de tempo real utilizando métodos ágeis.
O trabalho de integração requer muita experiência e habilidade para aumentar a capacidade de extrair testes e resultados do modelo do RRRT RQA para garantir o funcionamento perfeito de todo o sistema embarcado de tempo real.
A implementação do modelo integrado utilizando RRRT e RQA em nuvem proporcionou uma grande agilidade no desenvolvimento das diversas turmas de teste, e desenvolvimento de sistemas embarcados.
4.
RECOMENDAÇÕESO analise de qualidade, confiabilidade e segurança estão agora com os sistemas em nuvens incorporando um novo conceito que é o “Privacy”, onde o conceito de proteger os dados e informações de usuários está ganhando uma nova dimensão.
Recomenda-se também melhorar a qualidade das interações entre os times e o PO das diversas matérias, isso pode eliminar o desperdício de tempo.
5.
SUGESTÕES SOBRE TRABALHOS FUTUROSO Recomendo o estudo mais aprofundado de arquiteturas de hardware como “appliances” que podem ser utilizados em nuvem.
REFERÊNCIAS BIBLIOGRÁFICAS
CUNHA, Adilson. CE-230 – QUALIDADE, CONFIABILIDADE E SEGURANÇA
DE SOFTWARE - 2012
16
CUNHA, Adilson. HANDBOOK OF SOFTWARE QUALITY ASSURANCE – Fourth
Edition
ANEXOS
ANEXO 1
Prova de Conceito (Proof of Concept – PoC) da Aplicação do Estudo de Caso (Problem Based Learning – PBL) no Protótipo do SETRAIF
