Este documento resume um relatório sobre o desenvolvimento ágil de um Dispositivo de Comunicação na Nuvem (DCN) utilizando testes de instrumentação, métricas e interações entre equipes. Foram realizados testes de unidade para validar a estrutura e código do DCN e métricas como Halstead e complexidade ciclomática foram utilizadas para analisar a qualidade do código. Equipes interagiram por meio de ferramentas remotas para garantir qualidade, confiabilidade e segurança do produto.

1. ListEx 3 - CE-230
Dispositivo de Comunicação na Nuvem (DCN)
Prof. Dr. Adilson Marques da Cunha
Glaydson Luiz Bertoze Lima
Jefferson Andrade de Oliveira Junior
Manasseis Alves Ferreira
Thoris Ângelo Pivetta
ITA – PG/EEC-I – CE-230 – Outubro de 2012

2. AGENDA
● Introdução
● Teste de Instrumentação (Harness Test)
● Plano de Garantia da Qualidade - PGQ com Adaptação
(Tailoring) para o Desenvolvimento Ágil do subproduto
DCN
● Interações com o time do DCN
● Métricas do RTRT
● Recomendações
● Conclusões

3. Teste de Instrumentação (Harness Test)
● Criação do HappyTest

4. Teste de Instrumentação (Harness Test)
● Estrutura criada

5. Teste de Instrumentação (Harness Test)
● Diagrama de Sequência Resultante

6. Teste de Instrumentação (Harness Test)
● Código-fonte gerado: https://sites.google.com/site/itajefferson/home/disciplinas-do-mestrado/ce-
230/listex-3/HarnessTestDCN.zip

7. PGQ - Plano de Garantia de Qualidade
● Propósito
Esse Plano de Garantia de Qualidade tem o propósito de
garantir que o dispositivo DCN estará de acordo com as
normas e requisitos do cliente.
Escopo
●
Garantir um conjunto de atividades planejadas e sistemáticas,
implementadas no sistema da qualidade e demonstradas
como necessárias, para prover confiança, segurança (safety)
e conformidade adequada de que o DCN atenderá os
requisitos para a qualidade.

8. Objetivos - PGQ
● Satisfação do cliente - É a combinação de conformidade
com os requisitos (o projeto deve produzir o que afirmou que
produziria) e adaptação ao uso (o produto ou serviço deve
satisfazer as necessidades reais), com segurança (safety) e
confiabilidade no uso;
● Prevenção sobre inspeção - O custo de prevenção de erros
em geral é muito menor que o custo de corrigi-los, conforme
revelado pela inspeção, mitigando possíveis riscos ao
controle e economia de recursos.
● Responsabilidade da gerência - Participação de todos os
membros da equipe, mas é sempre responsabilidade do SM
- Scrum Master para prover soluções a situações de conflito
ou indefinição, e prover os recursos necessários para que
exista sucesso.

9. Responsabilidades - PGQ
● Scrum Master é o gerente do projeto dentro do modelo
padrão de gerenciamento ágil através do Scrum. A principal
função do Scrum Master é ser o facilitador do processo
e ajudar as pessoas a resolver os problemas, enquanto
dissemina e a aplica o processo dentro da organização.
● Time Scrum deve ser multidisciplinar e auto-organizado,
devendo ser pequeno com no máximo 10 a 15
participantes.
● Product Owner é o cliente de um time Scrum, ele é
responsável pelo retorno do investimento do produto.

10. Métricas - PGQ
As métricas de produto, projeto e processo foram geradas
durante o ciclo de desenvolvimento. Para isso, utilizou-se a
ferramenta disponível no IBM-Rational Test RealTime.

11. RECOMENDAÇÕES - PGQ
● É desejável que a equipe que realizará os testes não seja
a mesma que tem a responsabilidade de geração do código.
● Cada processo de auditoria deve ser revisado. É
desejável que no quadro de revisores sejam inclusos os
usuários chave, indicados pelo cliente, de modo a gerar
comprometimento nos resultados dos testes.

12. Interações com a equipe
Utilizando ferramentas de comunicação remota houve a
interações entre as equipes envolvidas no
desenvolvimento Ágil do DCN (Dispositivo de
Comunicação na Nuvem) do SETRAIF. Foram relizadas
seis questões com respostas para aferição de
Qualidade, Confiabilidade e Segurança (Safety) do
produto.

13. Na Interação 01, foram elaboradas as
seguintes perguntas:

14. Na Interação 02, as perguntas foram as mesmas, com a
diferença delas serem disponibilizadas em na nuvem para criar
um documento único de resposta, facilitando a interação.

15. Na iteração 03, a foi realizada a seguinte
Pergunta:

16. Métricas RTRT - Halstead
Nome Símbolo Fórmula Descrição
Operadores OP "=",";","+" Palavras reservadas usadas em operações
Operandos OD "int", "x" Valores usados nas operações
Operadores Únicos UOP Palavras reservadas únicas usadas em operações
Operandos Únicos UOD Valores únicos usados nas operações
Tamanho LTH OP+OD Quantidade de operadores e operandos
Vocabulário VOC UOP+UOD Quantidade de operadores e operandos únicos
Dificuldade DIF (UOP/2)*(OD/UOD) Interpretação do código analisado
Volume VOL LHT*log2(VOC) Palavras necessárias para absorver o código analisado
Esforço EFF DIF*VOL Esforço mental para recriar o software
Bugs BUG VOL/3000 Estimativa de identificação de bugs
Tempo TIM EFF/18 Tempo estimado para implementar e testar a aplicação

17. Métricas RTRT - Vocabulário do Halstead

18. Métricas RTRT - Complexidade Ciclomática
* Métrica usada para indicar a complexidade da aplicação
* Mede a quantidade de caminhos de execução
independentes
M=E-N+2*P
Onde:
M = complexidade ciclomática
E = quantidade de setas
N = quantidade de nós
P = quantidade de componentes conectados

19. Métricas RTRT - Análise do Código Fonte

20. CONCLUSÕES

21. REFERÊNCIAS
[1] AGILEMANIFESTO. Manifesto for Agile
Development. Disponível em:
http://www.agilemanifesto.org - Acesso em: 28/10/2012
[2] Adpatworks, Definições SCRUM. Acesso em: http:
//www.adaptworks.com.br/treinamento/Certified-
ScrumMaster-CSM
[3] Material da disciplina CE-230. Disponível em:
https://sites.google.com/site/ce2302012/

22. OBRIGADO!