Novembro de 2009
Pós-Graduação em Engenharia Eletrônica e
Computação - Área Informática (PG/EEC-I)
Divisão de Ciência da Computação (IEC)
Relatório do Projeto Final
CES-63 e CE-235
Sistemas Embarcados e de Tempo Real
CE-230
Qualidade, Confiabilidade e Segurança (Safety) de
Software
Prof. Dr. Adilson Marques da Cunha Prof. Dr. Luiz Alberto Vieira Dias
Sumário
1 Introdução ... 1
1.1 Motivação ... 1
1.2 Contexto ... 1
1.3 Objetivação do Protótipo de Sistemas de Software ... 2
1.4 Redução de Escopo ... 2
1.5 Especificação de Requisitos ... 2
1.6 Ordem de Apresentação do Projeto Final ... 4
2 Desenvolvimento ... 4
2.1 Processo de Desenvolvimento de Software ... 4
2.2 Linha Base Funcional ... 6
2.3 Linha Base Alocada ... 6
2.3.1 Elaboração do CSC-ADD ... 6
2.3.1.1 Requisitos Funcionais e Suplementares do CSC-ADD ... 9
2.3.1.2 Geração do Código em C++ do CSC-ADD ... 10
2.3.2 Elaboração do ICSC-PCD ... 11
2.3.2.1 Documentação do Modelo do ICSC-PCD ... 14
2.3.2.2 Geração do Código em C++ do ICSC-PCD ... 14
2.3.2.3 Verificação da Coesão entre os Artefatos gerados por CSC ao ICSC-PCD ... 14
2.4 Linha Base de Produto ... 15
2.4.1 Controle de Versão dos Documentos e Artefatos do ICSC-PCD ... 15
2.4.2 Métodos e/ou Operações do ICSC-PCD ... 15
2.4.3 Demonstração de chamadas de Métodos e/ou Operações no ICSC-PCD ... 16
2.4.4 Ciclo de Engenharia de Software (Engenharia Direta e Engenharia Reversa) ... 17
2.5 Qualidade, Confiabilidade e Segurança (Safety) de Software ... 19
2.5.1 Objetivo ... 19
2.5.2 Escopo ... 19
2.5.3 Lista de Exercício 1 (ListEx 01) ... 19
2.5.3.1 Plano de Garantia da Qualidade (PGQ) da USC-GDS ... 20
2.5.3.2 Plano de Testes (PDT) da USC-GDS ... 21
2.5.4 Lista de Exercício 2 (ListEx 02) ... 22
2.5.4.1 Estimativa de Esforços por Pontos de Casos de Uso (EEPCU) ... 23
2.5.5 Lista de Exercício 3 (ListEx 03) ... 24
2.5.6 Lista de Exercício 4 (ListEx 04) ... 24
2.5.7 Métricas de Qualidade ... 24
3 Conclusão ... 26
3.1 Conclusão Específica e Genérica... 26
3.2 Recomendações e Sugestões... 26
4 Referencias Bibliográficas ... 27
1
1 Introdução
1.1 Motivação
A Bacia Amazônica está despertando a atenção de autoridades, organizações governamentais e não governamentais para o monitoramento dos seus valiosos recursos naturais e ambientais, gerando uma demanda tecnológica.
Esta demanda envolve Sistemas de Software Embarcados de Tempo Real que vem sendo objeto de investigação no ITA, como o Protótipo de Sistema Computadorizado ITA-ECO-SAT (Projeto Acadêmico do ITA para Monitoramento Ecológico de Plataformas de Coleta de Dados Hidrológicos via Satélite).
O desenvolvimento acadêmico de projetos como o ITA-ECO-SAT poderá servir de base para a formação de recursos humanos para este monitoramento de recursos naturais e artificiais, evitando assim, a ocorrência de desastres ecológicos, entre outros fatores ambientais.
1.2 Contexto
O Protótipo do Projeto ITA-ECO-SAT, a partir de Estações de Monitoramento e Controle de Plataformas de Coleta de Dados e Satélite Artificial, utiliza-se de dados oriundos de 02 (dois) tipos de Plataformas: 1) Dinâmicas como os Satélites Artificiais do tipo Equatorial de Monitoramento Ecológico (SAT’s); e 2) Estáticas como as Plataformas de Coletas de Dados (PCD’s) localizados em uma bacia hidrográfica de referência, neste caso a Bacia Amazônica. Tais PCD’s estáticas possuem a funcionalidade de aquisição e envio dos dados hidrológicos e meteorológicos para uma Estação de Comunicação das PCD’s (ECP), via Comunicação de Dados (CDD).
Essas funcionalidades subsidiam a tomada de decisão dos responsáveis na ECP, vulgo Sala de Situação da ANA (Agência Nacional de Águas), a fim de, possivelmente, efetuar o
armazenamento destas informações, bem como acionar a defesa civil para que sejam tomadas as devidas providências.
1.3 Objetivação do Protótipo de Sistemas de Software
O problema consiste em dotar o Protótipo de Sistema Computadorizado ITA-ECO-SAT, durante o 2º semestre de 2009, de um Item de Configuração de Software de Computador (ICSC), para a realização de coletas, registros e transmissões de dados.
A solução proposta é desenvolver um Item de Configuração de Software de Computador (ICSC), até o final do 2º semestre de 2009, visando aumentar a qualidade, a precisão e a eficiência das informações fornecidas aos tomadores de decisão na Estação de Monitoramento e Controle.
1.4 Redução de Escopo
Este Relatório tem por objetivo demonstrar o desenvolvimento das Unidades de Software de Computador (USC’s) que compõem o Componente de Software de Computador (CSC), que por sua vez faz parte do Item de Configuração de Software de Computador Plataforma de Coleta de Dados (ICSC-PCD), que é um item importante dentro do contexto do Sistema de Software de Computador (SSC) ITA-ECO-SAT.
Em todas as integrações, não houve redução de escopo, visto que desde o início do projeto foi identificado pelos alunos, os 5 (cinco) mais ou menos 2 (dois) (no mínimo 3 (três) e no máximo 7 (sete)) requisitos, para cada USC. Com isso, todas as funcionalidades foram aplicadas ao terceiro nível de integração (ICSC), baseado nos requisitos pré-estabelecidos.
1.5 Especificação de Requisitos
O ICSC-PCD deverá ser capaz de propiciar as seguintes funções: · Funções de Aquisição de Dados (ADD):
o Gerenciamento de Sensores (GDS): (1) Ativações e Desativações de Sensores; (2) Recebimentos de Dados de Sensores; e (3) Alterações nas Frequências de Coletas de Dados, em períodos de tempo de 15, 30, 45 e 60 minutos.
o Tratamento de Dados de Sensores (TDS): (1) Recebimento de dados dos sensores; (2) Carregamento/Leitura de tabelas de conversão; (3) Ajustes de dados dos sensores, a partir da tabela de conversão; e (4) Disponibilizações de dados ajustados.
o Controle de Exceção (CEX-ADD): (1) Identificação de exceção; (2) Tratamento de exceção; e (3) Geração de Log de exceção.
· Funções de Registro de Dados (RGD):
o Armazenamento de Dados (AMD): (1) Recebimento de Dados Enviados; (2) Armazenamento de Dados Enviados; e (3) Recuperação de Dados Armazenados.
o Distribuição de Dados (DDD): (1) Obtenção de dados armazenados pela USC-AMD; (2) Aplicação de critérios estatísticos aos dados, antes de sua distribuição; e (3) Envio de dados hidrometereológicos e operacionais a USC-GDC.
o Controle de Exceção (CEX-RGD): (1) Verificação de ocorrência de exceções durante o armazenamento de dados; (2) Verificação de ocorrência de exceções, durante a distribuição de dados; e (3) Envio das exceções geradas à USC-GDM.
· Funções de Gerenciador de Tarefas (GDT):
o Gerenciamento de Coletas (GCL): (1) Verificação de Operacionalidades de Sensores; (2) Recebimento de Parâmetros de Coleta, a partir de telecomandos recebidos da USC-ITG; e (3) Envio de Situações (Status) dos Resultados de Coletas para a USC-CEX-ADD.
o Gerenciamento de Comunicação (GDC): (1) Recebimento de dados, a partir de telecomandos recebidos da USC-DDD; (2) Envio de dados hidrometereológicos e operacionais para a USC-DHL e USC-DOP; e (3) Comunicação com a USC-ALT do recebimento de mensagens de alerta.
o Gerenciamento de Manutenção (GDM): (1) Recebimento atualizações de firmware (USC - AFW); (2) Captura de exceções (USC - CEX); e (3) Envio de alerta para USC - GDC.
1.6 Ordem de Apresentação do Projeto Final
Na seção 1, apresenta-se a Motivação, o Contexto, o Objetivo Protótipo de Sistemas de Software, a Redução do Escopo e a Especificação de Requisitos do Projeto Final.
O desenvolvimento do trabalho, composto pelas 04 fases do RUP (Iniciação, Elaboração, Concepção e Produto) é apresentado na seção 2.
Finalmente, na seção 3, são sintetizadas as principais conclusões do projeto, seguido de recomendações e sugestões para trabalhos futuros.
2 Desenvolvimento
2.1 Processo de Desenvolvimento de Software
O processo de desenvolvimento de software compreende todas as atividades necessárias para definir, desenvolver, testar e manter um produto de software. Alguns objetivos de um processo de desenvolvimento são: definir quais as atividades a serem executadas ao longo do projeto; quando, como e por quem tais atividades serão executadas; prover pontos de controle para verificar o andamento do desenvolvimento; padronizar a forma de desenvolver software em uma organização [1].
O projeto acadêmico ITA-ECO-SAT foi adotado como processo de desenvolvimento o Rational
Unified Process (RUP). O RUP estabelece para o desenvolvimento de produtos de software fases
e atividades. São compreendidas as fases e Iniciação, Elaboração, Construção e Transição. Para todas essas fases existem as disciplinas de Levantamento de Requisitos, Análise de Requisitos, Projeto, Implementação, Testes, Implantação, entre outras. A Figura 1 ilustra o RUP.
Figura 1: RUP para Pequenos Projetos [2] [3]
O encadeamento das fases e disciplinas para a construção do sistema dá se o nome de Ciclo de Vida, visto que existem diversos modelos de ciclos de vida. A diferença entre um do outro esta na forma como estabelece o encadeamento. O RUP adota o modelo de ciclo de vida Iterativo e Incremental [5].
Em um processo de desenvolvimento seguindo essa abordagem divide o desenvolvimento de um produto de software em ciclos. Em cada ciclo de desenvolvimento, podem ser identificadas todas as fases descritas no processo. Essa característica contrasta com a abordagem clássica, na qual as fases são realizadas em uma única vez [5].
O desenvolvimento de software é uma tarefa cooperativa tendo a necessidade de ser realizado em equipe. O RUP organiza os participantes do processo em papéis, como por exemplo, Gerente de Projeto, Analista de Sistemas, Desenvolvedor, Usuários, entre outras. Essa organização facilita nas atribuições de responsabilidades [4].
2.2 Linha Base Funcional
Na primeira fase do RUP (iniciação) foram desenvolvidos para cada uma das Unidades de Software de Computador (USC’s) os artefatos de Visão (VIS), Modelo de Casos de Uso (MCU), Glossário (GLO) e Casos de Teste (CDT) (Lista de Exercícios 1 – ListEx 1).
A Linha Base Funcional se encontra entre as fases de iniciação e elaboração. Nesse meio termo, foram consolidados, para os Componentes de Software de Computador (CSC’s), os artefatos desenvolvidos na fase de iniciação e acrescentados 2 (dois) artefatos adicionais, os quais são: Linha Base Funcional (LBF) ou Solicitação dos Principais Envolvidos (SPE) e Plano de Gerenciamento de Requisitos (PGR) (Lista de Exercícios 2 – ListEx 2).
2.3 Linha Base Alocada
2.3.1 Elaboração do CSC-ADD
Na fase de elaboração foram alocados os papéis a serem desenvolvidos por cada integrante desta equipe. Com isso, no caso específico do Componente de Software de Computador Aquisição de Dados (CSC-ADD), os papéis foram divididos da seguinte forma: Desenvolvedor e Analista de Sistemas – Jedson, Analista de Sistemas – Francisco e Gerente de Configuração e Mudanças – Simões (Lista de Exercícios 3 – ListEx 3).
Nesta fase da Linha Base Abocada (Fase de Construção) foram compilados, no Rational Rose
RealTime (RRRT), os seguintes diagramas do CSC-ADD:
c) Diagrama de Estados (Principal):
e) Diagrama de Sequencia (Exemplo do Gerenciamento de Sensores (GDS)):
Existem outros diagramas de Estados, Estrutura e também de Sequência, visto que os Diagramas de Sequência foram gerados automaticamente em tempo de execução. Os demais diagramas do CSC-ADD poderão ser visualizados no Anexo A.
2.3.1.1 Requisitos Funcionais e Suplementares do CSC-ADD
Foi realizada a traçabilidade dos requisitos e das características baseado nos artefatos gerados para o desenvolvimento do Componente de Software de Computador (CSC) Aquisição de Dados (ADD). A Figura 7, demonstra a realização da traçabilidade no Software Básico RequisitePro.
Figura 7 – Traçabilidade no Software Básico RequisitePro do CSC-ADD 2.3.1.2 Geração do Código em C++ do CSC-ADD
Após o desenvolvimento do modelo na ferramenta Rational Rose RealTime (RRRT) foram geradas 3.458 linhas de código, com um total de 7(sete) arquivos *.cpp e 7 (sete) arquivos *.h, como pode ser visto na Figura 8.
2.3.2 Elaboração do ICSC-PCD
Durante a primeira Fase de Construção foi desenvolvido os CSC’s, correspondentes, aos ICSC’s do Projeto ITA-ECO-SAT. No caso do ICSC-PCD foram desenvolvidos os Componentes de Software de Computador (CSC) Aquisição de Dados (ADD), Registro de Dados (RGD) e Gerenciador de Tarefas (GDT).
Ao final da Fase de Construção foram integrados os 3 (três) CSC, desenvolvido no início desta fase, ao ICSC-PCD. Com isso, fez se necessário consolidar os diagramas desenvolvidos por cada grupo de CSC em um único Projeto de Workspace, do Modelo na Ferramenta Rational Rose RealTime (RRRT), ou seja, aplicar as funcionalidades integradas a um único ICSC.
Ainda na Linha Base Abocada (final da Fase de Construção) foram compilados, no RRRT, os seguintes diagramas do ICSC-PCD:
b) Diagrama de Classes:
d) Diagrama de Estrutura:
Existem os demais diagramas de Estados, Estrutura e também de Sequência, visto que os Diagramas de Sequência foram gerados automaticamente em tempo de execução. Os demais diagramas do ICSC-PCD poderão ser visualizados no Anexo B.
2.3.2.1 Documentação do Modelo do ICSC-PCD
Na ferramenta Ratinal Rose RealTime (RRRT), foi possível gerar toda a documentação do Modelo desenvolvido para o CSC-ADD (Tools -> Web Publisher), podendo ser visualizado na Página de Índices dos Autores. Note que a documentação está em HTML e publicado num pacote compactado, com isso o mesmo deverá ser descompactado e logo após executado o arquivo “root.html” [6].
2.3.2.2 Geração do Código em C++ do ICSC-PCD
Após o desenvolvimento do modelo na ferramenta Rational Rose RealTime (RRRT) foram geradas 13.196 linhas de código, com um total de 29 (vinte e nove) arquivos *.cpp e 29 (vinte e nove) arquivos *.h, como pode ser visto na Figura 9.
Figura 9 – Código gerado em C++ do ICSC-PCD
2.3.2.3 Verificação da Coesão entre os Artefatos gerados por CSC ao ICSC-PCD
Conforme pode ser visto na figura da seção “Requisitos Funcionais e Suplementares” que corresponde a traçabilidade dos requisitos identificados nos artefatos e que foram implementados e testados no modelo desenvolvido. Sendo assim, ficou confirmado que o modelo está coeso com relação aos artefatos.
2.4 Linha Base de Produto
2.4.1 Controle de Versão dos Documentos e Artefatos do ICSC-PCD
O Controle de Versão dos Documentos e Artefatos foi realizado utilizando TortoiseSVN (Subversion) desde o início da consolidação dos mesmo, atualmente, estão permanecidas as versão sobre o ICSC-PCD como pode ser visualizado na Figura a seguir.
Figura 10 – Controle de Versão no Subversion do ICSC-PCD
2.4.2 Métodos e/ou Operações do ICSC-PCD
Na Figura 11 demonstra a criação de 06 (seis) métodos e/ou operações que são utilizados entre cápsulas, a fim de realizar comunicações, bem como envio de dados.
Figura 11 – Controle de Versão no Subversion do ICSC-PCD
2.4.3 Demonstração de chamadas de Métodos e/ou Operações no ICSC-PCD
Na Figura 12 demonstra 02 (duas) chamadas de métodos da Unidade de Software de Computador Gerenciamento de Sensores– USC-GDT, na cápsula ADD_GDS_GerenciamentoDeSensores. Os Métodos mencionados na Figura 12 enviam os dados para o Tratamento dos Dados dos Sensores (TDS), o qual é outro USC.Figura 12 – Demonstração de Métodos que Envia Dados Para o TDS e Mostra o Status dos Sensores
Na Figura 13 demonstra 02 (duas) chamadas de métodos da Unidade de Software de Computador Gerenciamento de Comunicação– USC-GDC, na cápsula ADD_GDC_GerenciamentoDe
Comunicacao. Os Métodos mencionados na Figura 13 enviam os dados Hidrológicos e Operacionais para as Cápsulas Externas ao ICSC-PCD.
Figura 13 – Demonstração de Métodos que Envia Dados Hidrológicos e Operacionais para as Cápsulas Externas ao ICSC-PCD
2.4.4 Ciclo de Engenharia de Software (Engenharia Direta e Engenharia
Reversa)
O projeto do ICSC-PCD foi implementado através de engenharia direta e, quando necessário, engenharia reversa. Na engenharia direta foi importado um Modelo Cliente Socket para a realização de troca de mensagens, por meio de comunicações TCP/IP (esse modelo foi disponibilizado pelos monitores da disciplina), visando o cumprimento com a Missão Atribuída pelo professor da disciplina. Para isso foram criados os diagramas de estados e estruturas necessários para representar a implantação e comunicação entre os ICSC’s, ilustrada na Figura 14.
Figura 14 – TopCapsule do Modelo Cliente, contendo a Cápsula Client e a TopCapsule do Modelo do ICSC-PCD
A engenharia reversa é feita através da alteração do código diretamente e posterior sincronização com os diagramas criados no inicio. Segue abaixo a Figura 15 ilustrando o processo de sincronização do código com os diagramas.
2.5 Qualidade, Confiabilidade e Segurança (Safety) de Software
2.5.1 Objetivo
O objetivo desta seção é consolidar a aplicação dos principais conhecimentos teóricos adquiridos na Disciplina CE-230, durante o processo de desenvolvimento com enfoque em Qualidade, Confiabilidade e Segurança de Software do Protótipo do Sistema de Software Embarcado e de Tempo Real para o Projeto ITA-ECO-SAT, visando melhorar a eficiência e reduzir o desperdício de recursos envolvidos.
2.5.2 Escopo
O escopo deste relatório é: 1) Consolidação dos principais resultados obtidos nas 4 (quatro) Listas de exercícios realizadas da disciplina CE-230; 2) Comparação da Estimativa de Esforço de Desenvolvimento por Pontos de Casos de Uso (Caio Monteiro) da Unidade de Software de Computador (USC-GDS) e a sua realização prática ao final da disciplina; e 3) Apresentação de 3 (três) exemplos de implementação de métricas significativas de Qualidade, Confiabilidade ou Segurança envolvendo a USC-GDS.
2.5.3 Lista de Exercício 1 (ListEx 01)
Nesta Lista de Exercícios, inicialmente foram requisitados as atualizações e/ou criações de um portal para cada aluno, utilizando-se do Software Básico GoogleSites, a fim de melhorar as publicações dos relatórios e documentos realizados pelo(s) aluno(s), bem como o versionamento dos mesmos, atendendo ao padrão pré-estabelecido pelo professor da disciplina.
A Ferramenta MS Project Versão 2007 Professional propiciou o Gerenciamento do Desenvolvimento do Projeto ITA-ECO-SAT, na segunda parte desta lista de exercícios. Por meio deste foi possível gerenciar o tempo de Desenvolvimento da Unidade de Software de Computador Gerenciamento de Sensores (USC-GDS), o qual compreende na realização dos mínimos, necessários e suficientes Artefatos do RUP, tais como: Visão, Modelo de Casos de Uso, Casos de
Teste e Glossário, a partir dos 10 (dez) existentes, que incluem modelagem do sistema, entre outras funcionalidades.
E por fim foram criados os artefatos de Plano de Garantia da Qualidade (PGQ), Plano de Testes (PDT) e Casos de Teste (CDT) para a Unidade de Software de Computador (USC-GDS).
2.5.3.1 Plano de Garantia da Qualidade (PGQ) da USC-GDS
As definições mais relevantes do Plano de Garantia da Qualidade referem-se aos objetivos da Qualidade e ao Plano de Revisões e Auditorias.
Os objetivos da Qualidade no desenvolvimento da USC-GDS, baseados no PMBOK, estão descritos abaixo:
· Satisfação do cliente à entender, gerenciar e influenciar as necessidades de forma que as expectativas do cliente sejam atendidas. Isso requer a combinação de conformidade com os requisitos (o projeto deve produzir o que foi dito que produziria) com adequação ao uso (o produto deve satisfazer as reais necessidades);
· Prevenção ao invés de correção à o custo da prevenção de erros é sempre menor que o custo de corrigi-los; e
· Aderência ao processo definido no documento Caso de Desenvolvimento do GDS. O Plano de Revisões de Auditorias inclui:
· Revisões: o Revisão do Processo; o Revisão de Requisitos; o Revisão de Arquitetura; e o Revisões de projeto. · Auditorias:
2.5.3.2 Plano de Testes (PDT) da USC-GDS
O plano de teste está em reunir todas as informações necessárias ao planejamento e ao controle do esforço de teste referente ao Item de Configuração de Software de Computador Plataforma de Coleta de Dados (ICSC-PCD) do Projeto ITA-ECO-SAT.
O principal objetivo está em: 1) identificar os itens-alvo; 2) descrever a abordagem adotada; 3) identificar os recursos necessários; e 4) listar os itens que não serão testados. Os itens-alvos foram 27 funcionais.
A estrutura do artefato foi esquematizada em introdução; itens-alvo; funcionalidades a serem testadas e não testadas (casos de teste); estratégia de teste (atividades e ferramentas utilizadas); critério de sucesso ou falha, suspensão e requisitos de reinício; resultados de teste (relatórios); hardware e software necessários; papeis desempenhados, recursos humanos e treinamento; cronograma; riscos; e aprovação do documento.
Os seguintes testes foram incluídos: · Ativar e Desativar Sensores Objetivo do Tipo de
Teste
Verifica se o sistema possibilita as configurações de ativação e desativação de sensores.
Técnica Uma Unidade de Software de Computador deverá se comunicar com a outra.
Critério de Êxito O sensor deverá estar operacional. Considerações
Especiais
Para execução deste teste deve se ter assegurada a capacidade de outra USC gerar mensagens com prioridade elevada.
· Alterar a Periodicidade de Coleta Objetivo do Tipo de
Teste
Verifica se o sistema possibilita as configurações de alteração da periodicidades da coleta de dados.
com a outra.
Critério de Êxito O sensor deverá estar operacional. Considerações
Especiais
Para execução deste teste deve se ter assegurada a capacidade de outra USC gerar mensagens com prioridade elevada.
· Adquirir Dados Objetivo do Tipo de Teste
Verifica se o sistema possibilita o recebimento de dados de sensores.
Técnica Uma Unidade de Software de Computador deverá solicitar o
status do recebimento dos dados.
Critério de Êxito O sensor deverá estar configurado corretamente. Considerações
Especiais
Restrições de tempo de resposta deverão ser levadas em conta.
2.5.4 Lista de Exercício 2 (ListEx 02)
Para atender às necessidades de desenvolvimento do Componente de Software de Computador Aquisição de Dados (CSC-ADD), nesta lista de exercícios foram estendidas e integradas as Estimativas de Esforços por Pontos de Caso de Uso (EEPCU) realizadas nas Matérias CES-63 e CE-235 das USCs (ListEx 01), consolidando com as demais EEPCU das USCs ao CSC-ADD, q qual foi publicada, individualmente, na página de índices de cada aluno.
A Norma IEEE Std 830-1998 (Recommended Practice For Software Requirements Specifications) foi publicado e apresentado (em 15 minutos) atendendo aos padrões e Modelos de Qualidade, Confiabilidade ou Segurança (Safety) de Software de interesse às Práticas Recomendadas para Especificação de Requisitos para Software.
Os artefatos de Plano de Testes (PDT), Caso de Teste (CDT) e Plano de Garantia de Qualidade (PGQ) elaborados na ListEx 01 foram estendidos, integrados e consolidados, a fim de atender as
necessidades do Componente de Software de Computador (CSC) da USC-GDS, incluindo os Diagramas de Seqüência dos Casos de Teste do CSC-ADD, os quais foram criados, automaticamente, em tempo de execução do modelo.
2.5.4.1 Estimativa de Esforços por Pontos de Casos de Uso (EEPCU)
Estimativas de Esforços por Pontos de Caso de Uso conforme ListEx 2. Cada equipe adotou um critério diferente para estimar prazos. Neste cenário, o GDT é concluído 11 meses após o ADD. Os desenvolvedores do ADD e do RGD poderiam ajudar a terminar o GDT em menor prazo. Não foram considerados os esforços de integração dos CSC’s no ICSC PCD.
Considerando a dedicação 100h/mês para cada membro da equipe foram previstos 06 (seis) meses e 07 (sete) dias, mas foi realizado em 04 (quatro) meses (agosto 2009 a novembro 2009). Com isso, as prováveis causas da maior produtividade são devido às definições já estarem prontas desde o início do Projeto ITA-ECO-SAT, bem como o mesmo ter o escopo reduzido com relação ao projeto real, como ilustra a Figura a seguir.
2.5.5 Lista de Exercício 3 (ListEx 03)
Durante esta lista foram realizados os 08 (oito) Warm-ups (tutorial de aprendizado da ferramenta
Rational Rose RealTime (RRRT)), os quais serviram de base para o entendimento de todo o
funcionamento dos modelos realizados para Sistemas Embarcados de Tempo Real. Porém, para esta disciplina, CE-230, o Warm-up 8 foi obrigatório, por que estendeu os testes de instrumentação (Harness Test), utilizando o RQA, baseando-se em Diagramas de Sequência. Com isso, foi reportado a realização de um Teste de Instrumentação (Harness Test), utilizando o RQA, do CSC-ADD, a partir do Diagrama de Sequência, (praticado na ListEx 02), gerando-se o código-fonte em C++.
2.5.6 Lista de Exercício 4 (ListEx 04)
O primeiro requisito da ListEx 4 foi a avaliação oral, individual, realizada pelos monitores e o professor da disciplina, baseando-se no warm-up 8 praticado na ListEx 03.
Posteriormente foi publicar, individualmente, um relatório em grupo, reportando a realização de um Teste de Instrumentação (Harness Test), utilizandoo RQA (praticado na ListEx 03), no ICSC-PCD, gerando-se o código-fonte em C++. Cada aluno ficou responsável em relatar em uma seção do relatório sua participação (individual) desde o início do Projeto ITA-ECO-SAT.
2.5.7 Métricas de Qualidade
As métricas de qualidade foram levantadas do código ICSC-PCD.cpp, usando a Análise de Sensibilidade e avaliados no Kiviat. Para avaliar a qualidade do código gerado no RRRT para o ICSC-PCD, implementaram-se as métricas: 1) Número de comentários; 2) Número de Linhas; 3) Complexidade; e 4) Profundidade.
Após a análese de sensibilidade foi verificado alguns pontos críticos que se encontra fora do escopo de avaliação, com isso foram alteradas as complexidades a fim de testar a qualidade do código, como pode ser visualizado nas Figuras a seguir.
Durante a análise foi difícil verificar onde está a complexidade do código. Com isso, foi alterado os códigos fontes do modelo gerado, de “swith() case” para “if()”, atendendo as mesmas funcionalidades adquiridas desde o código original. Por conseguinte, ilustra as modificações realizadas no código gerado.
3 Conclusão
3.1 Conclusão Específica e Genérica
Todas as etapas propostas foram realizadas de forma eficaz comprovando que a metodologia utilizada nas disciplinas CES-63, CE-235 e CE-230, aplicam-se ao desenvolvimento de Projetos com número elevado de desenvolvedores e alta complexidade, em curto, médio e longo prazo. Com isso, em apenas 16 semanas foi possível implantar o Software no Hardware, a partir do código gerado em C++ do Modelo do ICSC-PCD, em Mini PC Daruma (processador x86).
A redução de escopo realizada nas integrações das USC’s para o CSC e dos CSC’s para o ICSC-PCD viabilizaram a realização das funcionalidades previstas inicialmente e não houve alterações na identidade das USCs propostas.
Para a realização dos testes de qualidade, confiabilidade e segurança (safety) de software foi possível exercitar, na prática, diversas técnicas vistas em aula. O RRRT propiciou grande produtividade nos Testes de Instrumentação (Harness Test), onde uma equipe de 08 (oito) pessoas dedicaram-se parcialmente, desde o início em 22/09/09 (ListEx 2) e Término em 22/11/09 (Integração) totalizando 2 (dois) meses, visto que o Teste de Instrumentação criado para a ICSC PCD propiciou a verificação de todos os 27 requisitos propostos.
3.2 Recomendações e Sugestões
No próximo ano será necessário que haja uma iteração entre os grupos de ICSC’s, no início do curso visando uma padronização de mensagens e protocolos trocados entre eles, a fim de evitar retrabalho no processo de integração, bem como interferir nos testes de qualidade, confiabilidade e segurança (safety) de software.
De acordo com os requisitos da disciplina, a geração e compilação do código foi realizada em C++. Os alunos poderiam realizar experimentos de portabilidade do Modelo, bem como a compilação e execução de diferentes linguagens e Sistemas Operacionais, garantindo assim a qualidade do produto.
4 Referencias Bibliográficas
[1] BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. Editora Campus: 6ª Edição. 2002.
[2] CUNHA, A. M., Dias, L. A. V. Página de Índices da Disciplina CES63 – Sistemas Embarcado, 2009. Disponível em http://sites.google.com/site/ces63ita/. Acesso em 28 nov. 2009.
[3] CUNHA, A. M., Dias, L. A. V. Página de Índices da Disciplina CE-235 – Sistemas Embarcados de Tempo Real, 2009. Disponível em http://sites.google.com/site/ce235ita/. Acesso em 28 nov. 2009.
[4] IBM. Rational Unified Process, 2009. Disponível em http://www.ibm.com/ Acesso em 28 nov. 2009.
[5] RATIONAL, S. C.. Rational Unified Process: Visão Geral, 2001. Disponível em http://www.wthreex.com/rup/. Acesso em 28 nov. 2009.
[6] FIGUEIREDO, J. Z.. Página de Índices do Jedson Zendron Figueiredo. Disponível em http://sites.google.com/site/jzfigueiredo/. Acesso em 29 nov. 2009.
ANEXO A
Anexo A.1 – Diagrama de Casos de Uso
Na Figura a seguir demonstra o Diagrama de Casos de Uso do CSC-ADD, com os seus respectivos atores e casos de uso. Note que o mesmo foi elaborado de acordo com as especificações de requisitos, bem como o artefato de Modelo de Casos de Uso (MCU).
Diagrama de Casos de Uso do Componente de Software de Computador Aquisição de Dados (CSC-ADD)
Anexo A.2 – Diagrama de Sequencia
Durante a execução do Sistema como um todo foi possível realizar a geração automática dos Diagramas de Sequencia, por meio da cápsula principal (TopCapsule)
realizando a seleção de quais cápsulas do Diagrama de Estrutura deseja-se visualizar os envios de sinais (Open Trace).
Abaixo são demonstrados alguns Diagramas de Sequencia do CSC-ADD, denominando fases da execução do Sistema, separando-os por Unidades de Software de Computadores (USC) a partir de cada requisito especificado no documento de Solicitação dos Principais Envolvidos (SPE).
Diagrama de Sequencia do CSC-ADD que representa as funcionalidades da USC-GDS
Diagrama de Sequencia do CSC-ADD que representa as funcionalidades da USC-TDS
Diagrama de Sequencia do CSC-ADD que representa as funcionalidades da USC-CEX-ADD
Anexo A.3 – Diagrama de Classes
O Diagrama de Classes do CSC-ADD está exposto na Figura baixo com as suas respectivas cápsulas e associações. O mesmo propicia as associações, ou seja, ligações que permite a comunicação entre as cápsulas através de objetos.
Diagrama de Classes do Componente de Software de Computador Aquisição de Dados (CSC-ADD)
Anexo A.4 – Diagrama de Estrutura
Esse diagrama permite conexões entre cápsulas, a criação de objetos das mesmas, bem como a geração automática de Diagramas de Sequencia durante a execução. Nas próximas Figuras são apresentados os Diagramas de Estrutura de cada cápsula.
Diagrama de Estrutura da Cápsula Aquisição de Dados (cápsula principal e/ou
TopCapsule)
Diagrama de Estrutura da Cápsula Coleta de Dados
Diagrama de Estrutura da Cápsula Controle De Exceção
Diagrama de Estrutura da Cápsula Sistema Embarcado
Diagrama de Estrutura da Cápsula Tratamento de Dados de Sensores Anexo A.5 – Diagrama de Estados
Nesta seção são demonstrados os Diagramas de Estados onde foi possível elaborar todas as transições de uma estado ao outro, ou mesmo, auto-transições, propiciando todo o fluxo de eventos que uma Máquina de Estado deve realizar. Logo abaixo são demonstrados os Diagramas de Estados do CSC-ADD.
Diagrama de Estados da Cápsula Sistema Embarcado
Diagrama de Estados da Cápsula Tratamento de Dados de Sensores
Diagrama de Estados da Cápsula Controle de Exceção
ANEXO B
Anexo B.1 – Diagrama de Casos de Uso do ICSC-PCD
Na Figura a seguir demonstra o Diagrama de Casos de Uso do ICSC-PCD, com os seus respectivos atores e casos de uso. Note que o mesmo foi elaborado de acordo com as especificações de requisitos, bem como o artefato de Modelo de Casos de Uso (MCU).
Diagrama de Casos de Uso do Componente de Software de Computador Aquisição de Dados (CSC-ADD)
Anexo B.2 – Diagrama de Sequência do ICSC-PCD
Durante a execução do Sistema como um todo foi possível realizar a geração automática dos Diagramas de Sequência, por meio da cápsula principal (TopCapsule) realizando a seleção de quais cápsulas do Diagrama de Estrutura deseja-se visualizar os envios de sinais (Open Trace).
Abaixo são demonstrados alguns Diagramas de Sequência do ICSC-PCD, denominando fases da execução do Sistema, separando-os por Unidades de Software de Computadores (USC) a partir de cada requisito especificado no documento de Solicitação dos Principais Envolvidos (SPE).
Diagrama de Sequência do IPCD que representa as funcionalidades da CSC-ADD
Diagrama de Sequência do IPCD que representa as funcionalidades da CSC-RGD
Diagrama de Sequência do IPCD que representa as funcionalidades da CSC-GDT
Anexo B.3 – Diagrama de Classes
O Diagrama de Classes do ICSC-PCD está exposto na Figura baixo com as suas respectivas cápsulas e associações. O mesmo propicia as associações, ou seja, ligações que permite a comunicação entre as cápsulas através de objetos.
Diagrama de Classes do Item de Configuração de Software de Computador Plataforma de Coleta de Dados (ICSC-PCD)
Anexo B.4 – Diagrama de Estrutura
Esse diagrama permite conexões entre cápsulas, a criação de objetos das mesmas, bem como a geração automática de Diagramas de Sequência durante a execução. Nas próximas Figuras são apresentados os Diagramas de Estrutura de cada cápsula.
Diagrama de Estrutura da Cápsula Plataforma de Coleta de Dados (cápsula principal e/ou TopCapsule)
Anexo B.5 – Diagrama de Estados
Nesta seção são demonstrados os Diagramas de Estados onde foi possível elaborar todas as transições de uma estado ao outro, ou mesmo, auto-transições, propiciando todo o fluxo de eventos que uma Máquina de Estado deve realizar. Logo abaixo são demonstrados os Diagramas de Estados do ICSC-PCD.
Diagrama de Estados da Cápsula Gerenciamento de Sensores
Diagrama de Estados da Cápsula Controle de Exceção – Aquisição de Dados
Diagrama de Estados da Cápsula Distribuição de Dados
Diagrama de Estados da Cápsula Gerenciamento de Coletas
