AGRADECIMENTOSfiles.isec.pt/DOCUMENTOS/SERVICOS/BIBLIO/teses/Tese_Mest_Joa… · apresenta informação necessária a que qualquer membro de uma equipa de Scrum consiga avaliar a

1

AGRADECIMENTOS

Agradeço a todos os que fizeram parte da minha vida. Todos me ajudaram a ser o que sou e o que faço hoje.

Agradeço à minha família por apostar e sustentar toda a minha formação académica. Agradeço muito o apoio que

me deram e agradeço todos os momentos que fizeram de mim o que sou hoje.

Agradeço à Joana, com quem namoro há largos anos e que me ajudou em muito a ser quem sou.

Para ti Joana, um grande beijo.

Agradeço a todos os meus amigos e, a todos que fizeram parte do meu percurso académico. Agradeço aos bons

professores por me terem transmitido o vosso conhecimento e aos professores menos bons que me deram

oportunidades de desenvolver a aptidão para aprender e dominar tudo por mim próprio. Essa capacidade tem sido

crucial.

Agradeço ao Dr. João Cunha pela orientação dada e pelas suas esplêndidas aulas, sem dúvida contribuíram imenso

para o meu Mestrado.

Agradeço ao Engº Pedro Feio por me ter orientado na ISA, aos membros da equipa iTelemetry com quem tive o

prazer de trabalhar a maior parte do tempo e toda a equipa de Software da ISA por me ter proporcionado uma

experiência de trabalho gratificante. Com a vossa ajuda, senti-me um membro de uma equipa de Software.

Agradeço também à ISA pela oportunidade de estagiar nas suas instalações integrado no departamento de

Software.

Agradeço também a todos os que partilham o seu conhecimento na Internet, seja em blogues, forums,

comunidades de desenvolvimento e em todos os que contribuem para o opensource. Sem vós, sem a vossa partilha,

sem a vossa atitude o mundo não seria o que é hoje.

SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr

2

RESUMO

Este relatório descreve o trabalho realizado na ISA, empresa que desenvolve hardware e software de telemetria e

comunicações M2M na qualidade de Software Developer e na qualidade de Scrum Advisor.

Na qualidade de Software Developer, é aqui descrita a plataforma iTelemetry e o trabalho realizado no iTelemetry.

São abordadas alguns dos trabalhos realizados. É abordada a criação de um dicionário de Excepções, como foi

testado uma aplicação Web com critérios de cobertura, como uma camada de integração foi modificada para o

padrão Plugin, e como o padrão Template em conjunto com os padrões Factory e Null foram utilizados para

reformular um serviço crucial na plataforma iTelemetry. É também apresentado como foi abordada a modelação

das periodicidades de comunicação de equipamentos e como foram elaborados vários protótipos e se

concretizaram em módulos no iTelemetry.

Na qualidade de Scrum Advisor, é descrito como funcionava o departamento de software e como o Scrum foi

adoptado por algumas equipas do departamento e como este utiliza o Scrum no dia-a-dia. A implementação do

Scrum pela equipa iTelemetry foi analisada, foi alvo de propostas de melhorias e esse trabalho é aqui apresentado.

A análise compreendeu a elaboração de um método para verificar a conformidade das regras Scrum utilizadas pela

equipa em relação às regras Scrum, a elaboração de um método para avaliar as práticas Scrum que complementa a

avaliação da conformidade das regras e um método para recolher indicadores de qualidade de um projecto onde o

Scrum é aplicado.

Como Scrum Advisor, foi ainda elaborado um guião para ajudar as equipas de software da ISA a melhorar as suas

implementações de Scrum.


3

ABSTRACT

This report tells the work done at ISA, a company who develops both its software and hardware for telemetry and

M2M communications as a Software Developer and as a Scrum Advisor.

As Software Developer, hereby is described the iTelemetry platform and the work done on it. Some of the work

made is described in details. It is described how an Exception Dictionary was created, how a Web Application was

tested with coverage-criteria, how an integration layer was refactored to match the Plug-In pattern and how the

Template pattern was used along with the Abstract Factory and Null patterns to redesign a crucial iTelemetry

service. It’s also described how the ISA equipment communications were modulated and how prototypes were

conducted and used in iTelemetry.

As Scrum Advisor, it’s described how the software department worked and how Scrum was adopted by some of

the software teams along with how Scrum is used every day. The iTelemetry team was subject of analysis and fix

proposals that are here described. The analysis was possible due to the creation of a method to check if a team was

following the Scrum Rules, along with the creation of a method to check the Scrum practices of a Scrum Team

thus complementing the Scrum Rule check, along with a method that defines some quality indicators of a project

developed under Scrum.

As Scrum Advisor, a guide was also created to help ISA software teams achieve better implementations of Scrum

by letting the team fix their problems.


4

PALAVRAS -CHAVE

Scrum

Telemetry

iTelemetry

Design Patterns

Bing

ISA

K EYWORDS

Scrum

Telemetry

iTelemetry

Design Patterns

Bing

ISA


5

Agradecimentos ............................................................................................................................................ 1

Resumo ......................................................................................................................................................... 2

Abstract ........................................................................................................................................................ 3

Palavras-Chave ............................................................................................................................................. 4

KeyWords ..................................................................................................................................................... 4

Índice ............................................................................................................................................................ 5

Anexos .......................................................................................................................................................... 7

Índice de Figuras .......................................................................................................................................... 8

Introdução ................................................................................................................................................... 12

1.1 ISA ............................................................................................................................................... 12 1.2 Projecto iTelemetry ...................................................................................................................... 13 1.3 Actividade de Scrum Advisor ...................................................................................................... 14 1.3.1 Objectivos..................................................................................................................................... 14 1.3.2 Trabalho Realizado....................................................................................................................... 15 1.4 Actividade de Developer – projecto iTelemetry ........................................................................... 17 1.4.1 Objectivos..................................................................................................................................... 17 1.4.2 Trabalho Realizado....................................................................................................................... 18

2 A metodologia Scrum ........................................................................................................................... 20

2.1 Resumo ......................................................................................................................................... 20 2.2 Scrum Framework ........................................................................................................................ 20 2.3 Papéis ........................................................................................................................................... 21

2.3.1 Scrum Master .................................................................................................................... 21

2.3.2 Product Owner .................................................................................................................. 22

2.3.3 Team Member ................................................................................................................... 22

2.3.4 Pigs & Chickens ................................................................................................................ 22

2.4 Actividades ................................................................................................................................... 23 2.4.1 Sprint Planning .................................................................................................................. 23

2.4.2 Daily Scrum Meeting ........................................................................................................ 24

2.4.3 Sprint ................................................................................................................................. 24

2.4.4 Sprint Retrospective .......................................................................................................... 24

2.4.5 Sprint Review .................................................................................................................... 25

2.5 Artefactos ..................................................................................................................................... 25 2.5.1 Product Backlog ................................................................................................................ 25

2.5.2 Sprint Backlog................................................................................................................... 26

2.5.3 Burndown Chart ................................................................................................................ 27

Í NDICE


6

3 O Scrum na ISA .................................................................................................................................... 29

3.1 Situação anterior ao Scrum ........................................................................................................... 29 3.1.1 Equipas .............................................................................................................................. 29

3.1.2 Metodologias ..................................................................................................................... 29

3.1.3 Problemas identificados .................................................................................................... 29

3.2 A adopção do Scrum .................................................................................................................... 30 3.2.1 Introdução do Scrum ......................................................................................................... 30

3.2.2 Integração de novos elementos no Scrum ......................................................................... 30

3.2.3 Ferramentas Usadas .......................................................................................................... 30

3.2.4 Independência das Equipas de Scrum ............................................................................... 32

3.2.5 Resultados da introdução do Scrum .................................................................................. 32

3.3 Conformidade Com Regras .......................................................................................................... 33 3.3.1 Método utilizado ............................................................................................................... 33

3.3.2 Resultados ......................................................................................................................... 35

3.4 Avaliação das Práticas de Scrum .................................................................................................. 35 3.4.1 Método Utilizado .............................................................................................................. 36

3.4.2 Resultados ......................................................................................................................... 39

3.5 Avaliação do Projecto .................................................................................................................. 39 3.5.1 Método Utilizado .............................................................................................................. 39

4 Melhorias Introduzidas ao Scrum da ISA ............................................................................................. 41

4.1 Primeira Intervenção .................................................................................................................... 41 4.1.1 Sprint Planning Meeting ................................................................................................... 41


4.1.3 Sprint ................................................................................................................................. 44

4.1.4 Sprint Review .................................................................................................................... 46

4.1.5 Sprint Retroespective ........................................................................................................ 46

4.2 Segunda Intervenção .................................................................................................................... 46 4.2.1 Sprint Planning .................................................................................................................. 46


4.2.3 Sprint ................................................................................................................................. 49

4.2.4 Sprint Review .................................................................................................................... 50

4.2.5 Sprint RetroSpective ......................................................................................................... 50

4.3 Terceira Intervenção ..................................................................................................................... 50 4.3.1 Problemas Identificados .................................................................................................... 50

4.3.2 Sugestões ........................................................................................................................... 52

5 Procedimentos para Melhoria Contínua do Scrum ............................................................................... 54

5.1 Objectivos..................................................................................................................................... 54 5.2 Conceito ....................................................................................................................................... 54 5.3 Ciclo de vida de Procedimentos para melhoria contínua do Scrum ............................................. 54

6 Developer no Projecto iTelemetry ........................................................................................................ 56


7

6.1 OverView Da Actividade ............................................................................................................. 56 6.2 Âmbito do projecto ....................................................................................................................... 56 6.3 Conceitos do projecto ................................................................................................................... 57

6.3.1 iCenter ............................................................................................................................... 59

6.4 Arquitectura iTelemetry ............................................................................................................... 60 6.4.1 Arquitectura Física ............................................................................................................ 60

6.4.2 Arquitectura Lógica .......................................................................................................... 61

6.5 Síntese de Trabalhos Realizados .................................................................................................. 66 6.5.1 Protótipo para Avaliar Velocidade de Leitura ................................................................... 67

6.5.2 Protótipo conteúdo georreferenciado com Bing Maps ...................................................... 70

6.5.3 Dicionário de Excepções ................................................................................................... 75

6.5.4 Periodicidades de comunicação ........................................................................................ 78

6.5.5 Reformulação do Serviço de Dados .................................................................................. 79

6.5.6 Gestão de Elementos ......................................................................................................... 85

6.5.7 Módulo de Estados ............................................................................................................ 87

6.5.8 Plug-in iCenterDLL .......................................................................................................... 94

6.5.9 Elaboração do Plano de Testes ao Backoffice ................................................................... 97

7 Considerações Finais .......................................................................................................................... 100

8 Referências ......................................................................................................................................... 102

ANEXOS

Anexo A – Processo Avaliação Scrum – Avaliação das Práticas Scrum “Avaliação Práticas Scrum.pdf”

Documento que apresenta as métricas para as práticas de Scrum e apresenta os indicadores de qualidade de um

projecto onde o Scrum é aplicado. As métricas e os indicadores são apresentados com informação que permite que

qualquer membro de uma equipa de Scrum consiga fazer uma avaliação das práticas de Scrum e do estado do

Projecto.

Anexo B – Processo Avaliação Scrum – Avaliação das Regras Scrum “Avaliação Regras Scrum.pdf”

Documento que apresenta as regras do Scrum, descrevendo qual o seu propósito na metodologia. O documento

apresenta informação necessária a que qualquer membro de uma equipa de Scrum consiga avaliar a conformidade

das regras aplicadas em relação ao Scrum.

Anexo C – Processo Melhoria Contínua “Processo Melhoria Continua.pdf”

Documento que descreve como é que uma equipa pode melhorar o seu desempenho a nível de Scrum,

introduzindo actividades que fazem com que a equipa traga para a Sprint Retrospective Meeting dados sobre a sua

performance para que esta possa reflectir sobre eles e melhorar o Scrum praticado.


8

Í NDICE DE FIGURAS

Figura 1 Aplicações disponibilizadas pelo iTelemetry ............................................................................................. 14

Figura 2 Actividades realizadas sobre Scrum ........................................................................................................... 16

Figura 3 Agile Manifesto.......................................................................................................................................... 20

Figura 4 Overview da Framework Scrum ................................................................................................................ 21

Figura 5 Compromisso vs Envolvimento ................................................................................................................. 22

Figura 6 Protecção da equipa ................................................................................................................................... 23

Figura 7 Product Backlog ......................................................................................................................................... 25

Figura 8 Sprint Backlog da ferramenta Version1 ..................................................................................................... 26

Figura 9 Sprint Backlog da ferramenta JIRA ........................................................................................................... 27

Figura 10 Burndown Chart ....................................................................................................................................... 28

Figura 11 ScreenShot Ferramenta Version1 ............................................................................................................. 31

Figura 12 Folha de Calculo para gestão Scrum ........................................................................................................ 31

Figura 13 Screenshot da ferramenta JIRA ................................................................................................................ 32

Figura 14 Relação dentre Actividades, Regras e Critérios de Avaliação ................................................................. 33

Figura 15 Quadro de Descrição da Regra ................................................................................................................. 34

Figura 16 Exemplo de uma Regra Daily Scrum Meeting ......................................................................................... 34

Figura 17 Excerto dos Critérios da Daily Scrum Meeting da equipa iTelemetry ..................................................... 35

Figura 18 Formulação Genérica de uma Métrica do Processo ................................................................................. 37

Figura 19 Exemplo de uma métrica da equipa ......................................................................................................... 38

Figura 20 Excerto da folha de cálculo das avaliações do Processo .......................................................................... 38

Figura 21 Formato de um indicador de qualidade .................................................................................................... 39

Figura 22 Exemplo de um Indicador de qualidade ................................................................................................... 40

Figura 23 Resultados da avaliação das regras Sprint Planning Sprint ...................................................................... 42


9

Figura 24 Resultados das Daily Scrum Meetings ..................................................................................................... 43

Figura 25 Resultado da avaliação da Sprint ............................................................................................................. 45

Figura 26 Extracto da Conformidade da Actividade Sprint...................................................................................... 47

Figura 27 Extracto da Conformidade da actividade Daily Scrum Meeting .............................................................. 48

Figura 28 Extracto da conformidade da actividade Sprint ....................................................................................... 49

Figura 29 Excerto da avaliação das métricas do Product Owner .............................................................................. 50

Figura 30 Excerto da avaliação das métricas para o planeamento ............................................................................ 51

Figura 31 Excerto da Avaliação das métricas de Agendamento ............................................................................... 51

Figura 32 Excerto da Avaliação das métricas do Processo....................................................................................... 51

Figura 33 Excerto da Avaliação das métricas da Equipa .......................................................................................... 51

Figura 34 Excerto da Avaliação das métricas de Reporto ........................................................................................ 52

Figura 35 Excerto da Avaliação das métricas de Engenharia e Infra-estrutura ........................................................ 52

Figura 36 Fluxograma dos procedimentos de melhoria contínua ............................................................................. 55

Figura 37 Conceito iTelemetry ................................................................................................................................. 57

Figura 38 Exemplo de Unidades .............................................................................................................................. 57

Figura 39 Dados transmitidos através de Tags ......................................................................................................... 58

Figura 40 Descritores de Tag atribuídos a dados transmitidos ................................................................................. 58

Figura 41 Elemento Tanque com alguns descritores de Tag .................................................................................... 58

Figura 42 Um local com elementos sob monitorização ............................................................................................ 59

Figura 43 Possíveis clientes de Telemetria ............................................................................................................... 59

Figura 44 Comunicação entre Unidades e iCenter ................................................................................................... 60

Figura 45 Arquitectura Física ................................................................................................................................... 61

Figura 46 Arquitectura Lógica iTelemetry ............................................................................................................... 62

Figura 47 Camada de Acesso a Dados do iTelemetry .............................................................................................. 62


10

Figura 48 Interface do iTelemetryDAL .................................................................................................................... 63

Figura 49 Componentes da Business Layer.............................................................................................................. 64

Figura 50 Desenho dos serviços iTelemetry ............................................................................................................. 65

Figura 51 Padrão de Desenho Model View Presenter (MVP) .................................................................................. 66

Figura 52 Modelo Aplicações Web iTelemetry ........................................................................................................ 66

Figura 53 Modelo Conceptual do Problema ............................................................................................................. 67

Figura 54 Modelo de Dados 1 .................................................................................................................................. 68



Figura 57 Aplicação final que tira partido do protótipo ........................................................................................... 70

Figura 58 Modelo Domínio Bing Maps ................................................................................................................... 71

Figura 59 Ponto de interesse sem descrição ............................................................................................................. 74

Figura 60 Ponto de interesse com descrição visível, visualizando parte do mapa de Portugal ................................ 74

Figura 61 Âmbito das excepções e Diagrama de Classes das Excepções ................................................................ 76

Figura 62 Diagrama de classes das Periodicidades .................................................................................................. 78

Figura 63 Entrada de Informação das Unidades no iTelemetry................................................................................ 79

Figura 64 Modelo de Domínio Processamento de Mensagens ................................................................................. 82

Figura 65 Diagrama de classes das Mensagens Protocolares ................................................................................... 83

Figura 66 Template do Processamento de AProtocolMessage ................................................................................. 83

Figura 67 Template do Coordenador de Processamento de Mensagens ................................................................... 84

Figura 68 ScreenShot da visualização de detalhes dos elementos ............................................................................ 85

Figura 69 Presenters distintos com necessidade de comunicação ............................................................................ 86

Figura 70 Entrada de dados no iTelemetry ............................................................................................................... 88

Figura 71 Screenshot do protótipo de pesquisa de unidades pelo estado de comunicação ....................................... 89


11

Figura 72 Screenshot do protótipo de resumo das comunicações ............................................................................ 89

Figura 73 GUI com acesso a mais informações das unidades .................................................................................. 91

Figura 74 Interacção entre componentes de modo Assíncrono ................................................................................ 91

Figura 75 Screenshot do resumo das comunicações dos clientes ............................................................................. 92

Figura 76 Estado da comunicação de uma unidade .................................................................................................. 93

Figura 77 Estados dos dados de uma unidade .......................................................................................................... 94

Figura 78 Interacções a testar no módulo de utilizadores ......................................................................................... 98

Figura 79 Grafo dos estados de visualização ............................................................................................................ 98


12

Este relatório apresenta os resultados do estágio realizado no âmbito da unidade curricular de Estágio ou Projecto

Industrial do Mestrado em Informática e Sistemas, Ramo de Desenvolvimento de Software.

O estágio decorreu nas instalações da ISA – Intelligent Sensing Anywhere, em Coimbra, tendo como principais

actividades a colaboração no desenvolvimento da plataforma iTelemetry e a avaliação e melhoria do Scrum

adoptado no departamento de software da ISA. O estágio teve início a 21 de Novembro 2009 e término a 2 de

Julho de 2010.

As duas tarefas ocorreram em paralelo, não havendo nenhum período de dedicação exclusivo a um dos papéis. A

análise de Scrum foi efectuada com especial ênfase na equipa do iTelemetry, dado que esta equipa utiliza a

metodologia em questão. Este relatório contém informação sobre o trabalho realizado no estágio, não entrando em

demasia nos detalhes técnicos, dando preferência e ênfase às abordagens tomadas para a resolução de problemas, e

à forma como o trabalho realizado trouxe valor à empresa.

A ISA é uma empresa de base tecnológica que desenvolve produtos e implementa soluções completas, para o

mercado global, nas áreas da Telemetria e Gestão Remota, Instrumentação, Automação e Controlo, assentes em

tecnologia e know-how específicos nos campos da electrónica, engenharia do software, sensores, telemetria e

controlo.

As soluções de telemetria e controlo da ISA são aplicáveis a um largo espectro de mercados verticais. Entre estes,

os primeiros em que a ISA adquiriu know-how e para os quais desenvolveu um conjunto de soluções completas,

chave-na-mão, reconhecidas e implementadas internacionalmente, foram o mercado da telemetria do ambiente

(monitorização da qualidade do ar e das águas) e o mercado da telemetria do gás e dos combustíveis líquidos

(monitorização de reservatórios e de contadores). Actualmente a oferta da ISA alargou-se já aos mercados da

Energia, da Segurança e da Saúde.

Uma das marcas distintivas da ISA é a sua capacidade de desenvolver novos produtos e soluções, inovando

continuamente, sendo este o garante da sua sobrevivência e prosperidade. De facto, desde a sua fundação que a

ISA possui um núcleo de pessoas dedicadas à I+D, investindo anualmente nesta actividade uma percentagem

significativa do seu volume de negócios.

Outra das características da ISA é o seu enfoque nos produtos e soluções dedicados ao mercado global.

I NTRODUÇÃO

1.1 ISA


13

Efectivamente, existe a preocupação permanente na escalabilidade e na internacionalização, quer dos produtos

desenvolvidos, quer dos serviços a eles associados, sendo, para tal, a qualidade um dos factores determinantes do

qual a ISA não abdica.

A capacidade da ISA desenvolver e exportar produtos inovadores e tecnologicamente avançados tem sido, ao

longo dos anos, reconhecida por diversas entidades que têm distinguido a ISA: Agência de Inovação, COTEC

Portugal - Associação Empresarial para a Inovação, Universidade de Coimbra, Câmara Municipal de Coimbra,

ICEP, laboratórios internacionais de certificação, entre outras.

O iTelemetry é uma plataforma de gestão de telemetria da ISA, tendo como objectivo abstrair as várias áreas de

negócio e comunicações, centralizando toda a gestão da telemetria da ISA.

O iTelemetry é, deste modo, denominada uma plataforma estruturante. O projecto serve como base para

aplicações, à semelhança de uma Framework de telemetria da ISA. Deste modo, o iTelemetry, actuando como

plataforma estruturante, permite o rápido desenvolvimento de aplicações de telemetria para a ISA e seus clientes.

A Figura 1 mostra como o iTelemetry serve as aplicações iBottleRack (gestão de abastecimentos de botijas de gás)

e iWaterWeb (gestão de caudais de água) aos clientes da ISA. Internamente, embora não mostrado na imagem, o

iTelemetry tem também uma aplicação BackOffice, usada internamente pela ISA para operações de configuração,

manutenção e monitorização dos serviços prestados aos seus clientes.

1.2 PROJECTO I TELEMETRY

SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy

14

A ISA, ao longo da sua actividade, tem criado aplicações de telemetria

resulta toda a informação e gestão de telemetria que o iTelemetr

desenvolvimento de aplicações de telemetria resume

dados de telemetria da ISA.

A equipa do iTelemetry utiliza o Scrum como me

software da ISA. A actividade de Scrum Advisor surgiu para verificar a adopção da metodologia e auxiliar a

melhoria desta.

1.3.1 OBJECTIVOS

O papel de Scrum Advisor teve como principais objectivos:

1.3 ACTIVIDADE DE SCRUM

DDeevveellooppeerr

Figura 1 Aplicações disponibilizadas pelo iTelemetry

A ISA, ao longo da sua actividade, tem criado aplicações de telemetria à medida para os seus cl

resulta toda a informação e gestão de telemetria que o iTelemetry oferece sob a forma de uma API. Assim, o

desenvolvimento de aplicações de telemetria resume-se à criação de um Front-End pois o iTelemetry gere toda os

A equipa do iTelemetry utiliza o Scrum como metodologia de trabalho assim como mais algumas equipas de


O papel de Scrum Advisor teve como principais objectivos:

CRUM ADVISOR

para os seus clientes, de onde

y oferece sob a forma de uma API. Assim, o

End pois o iTelemetry gere toda os

todologia de trabalho assim como mais algumas equipas de



15

• Analisar a adopção do Scrum na ISA

• Identificar problemas

• Sugerir melhorias

• Criar métricas para avaliar o Scrum

De acordo com estes objectivos, definiu-se que a actividade se separava em duas partes distintas: observação e

elaboração de uma proposta de melhoria.

A fase de observação do Scrum tinha como objectivo perceber e documentar se as equipas cumpriam com as

regras da metodologia, sendo uma actividade de natureza mais passiva. A informação recolhida nesta fase serviria

para perceber e analisar quais os aspectos que deviam ser mudados.

A fase da proposta de melhoria, com uma natureza mais activa, tem como objectivo elaborar acções de correcção

de modo que as práticas usadas pela equipa estejam mais de acordo com a o que é preconizado pela metodologia.

A análise que fundamenta a percepção da melhoria envolveu a elaboração de alguns mecanismos de avaliação e

uso de métricas para a metodologia, práticas e projecto onde o Scrum é aplicado.

Com esta actividade, pretende-se documentar e melhorar o Scrum seguido da ISA, assim como promover a sua

melhoria contínua.

1.3.2 TRABALHO REALIZADO

De acordo com os objectivos estabelecidos, foi necessário elaborar um plano de acção para cada objectivo:

• Análise da adopção do Scrum na ISA, documentando como é que o Scrum foi introduzido, e como os

elementos das equipas são introduzidos e integrados no Scrum. Para além destes pontos, avaliou-se até

que ponto a adopção do Scrum tem sido vantajosa para a ISA.

• Identificação de problemas na adopção da metodologia na ISA, justificando-os e especificando as suas

repercussões.

• Sugestão de melhorias para a metodologia adoptada, como resultado da análise dos problemas existentes.

• Criação de métricas para avaliação da metodologia, permitindo uma análise continuada da evolução

futura da metodologia.

A análise do Scrum na ISA foi elaborada através de reuniões com a chefe do departamento de software bem como

interrogando os vários colaboradores do departamento.


16

Para conseguir medir a eficácia da implementação adoptada na ISA, identificar os seus probl

melhorias foram realizadas as seguintes actividades:

O trabalho realizado sobre a medição da eficácia da adopção do Scrum e sugestão de melhorias foi focado na

equipa que integrei – iTelemetry e, com menos foco, numa segunda equipa

partilham o mesmo Scrum Master.

Tal como apresentado na Figura

• Elaborado um método para analisar o devido cumpr

• Analisado o cumprimento das regras do

• Elaborado um método para recolha de métricas para o

• Recolha de dados sobre a equipa iTelemetry e MaisGas de acordo com a avaliaçã

criadas.

• Elaboradas propostas de melhoria às práticas Scrum utilizadas pela equipa iTelemetry e MaisGas.

• Elaborado um guião para melhoria contínua para o departamento.

O trabalho realizado na actividade Scrum foi realizado com base

• Investigação sobre as implementações de Scrum em diferentes áreas.

• Investigação sobre as avaliações usadas para medir Scrum.

DDeevveellooppeerr

Para conseguir medir a eficácia da implementação adoptada na ISA, identificar os seus probl

melhorias foram realizadas as seguintes actividades:

Figura 2 Actividades realizadas sobre Scrum


iTelemetry e, com menos foco, numa segunda equipa – MaisGas. Ambas as equipas

partilham o mesmo Scrum Master.

Figura 2, foi efectuado o seguinte:

Elaborado um método para analisar o devido cumprimento das regras do Scrum

Analisado o cumprimento das regras do Scrum pela equipa iTelemetry em duas alturas distintas.

Elaborado um método para recolha de métricas para o Scrum

Recolha de dados sobre a equipa iTelemetry e MaisGas de acordo com a avaliaçã

Elaboradas propostas de melhoria às práticas Scrum utilizadas pela equipa iTelemetry e MaisGas.

para melhoria contínua para o departamento.

O trabalho realizado na actividade Scrum foi realizado com base em:

Investigação sobre as implementações de Scrum em diferentes áreas.

Investigação sobre as avaliações usadas para medir Scrum.

Para conseguir medir a eficácia da implementação adoptada na ISA, identificar os seus problemas e sugerir


MaisGas. Ambas as equipas

Scrum

pela equipa iTelemetry em duas alturas distintas.

Recolha de dados sobre a equipa iTelemetry e MaisGas de acordo com a avaliação de regras e métricas

Elaboradas propostas de melhoria às práticas Scrum utilizadas pela equipa iTelemetry e MaisGas.


17

• Leitura de case studies e blogs de sucesso e insucesso da adopção do Scrum.

Na actividade de Developer, pretende-se utilizar todos os conhecimentos técnicos para auxiliar a equipa

iTelemetry no desenvolvimento da plataforma iTelemetry da ISA.

1.4.1 OBJECTIVOS

Como developer da equipa iTelemetry, os objectivos previstos foram auxiliar a concepção e desenvolvimento de

alguns módulos para a plataforma iTelemetry:

• Aquisição de Dados – Módulo responsável pela aquisição de dados orientados da plataforma de

comunicações da ISA.

• Apresentação de Resultados – Módulo capaz de disponibilizar aos utilizadores finais os dados obtidos

através de telemetria.

• Módulo de Administração – Módulo onde se deve configurar qualquer entidade envolvida na telemetria.

Equipamentos de telemetria, locais, clientes, utilizadores etc.

• Módulo de Administração para Clientes – Módulo que fornece a clientes com responsabilidades

administrativas a gestão do sistema

• Módulo de Validação do Sistema – Tem como finalidade permitir aos responsáveis pela manutenção dos

sistemas de telemetria a validação de dados (automática e manual), comunicações dos equipamentos de

telemetria entre outros.

• Módulo de Manutenção do Sistema para Técnicos – Tem como objectivo auxiliar os técnicos na

instalação e manutenção de equipamentos no terreno.

A colaboração como developer dentro de uma equipa de Scrum abrangia trabalho sobre os vários níveis da criação

do software, sendo necessário aplicar os conhecimentos e práticas de Arquitectura de software, Modelação, Gestão

de Base de Dados, Web Development, Testing, Quality Assurance. Para além disso, também foi requerido o

domínio das tecnologias SQLServer, Javascript, Windows Forms, C#, asp.NET, Entity Framework 3.5,

Manipulação de imagens e Cascading Style Sheets.

Os desenvolvimentos planeados na proposta inicial abordavam as funcionalidades em falta na altura da proposta,

não sendo estipulado o trabalho a realizar em cada funcionalidade em falta.

Os desenvolvimentos efectuados durante o estágio acompanharam de perto as necessidades da plataforma de modo

a que a ISA pudesse responder às suas adjudicações. Como developer, o meu trabalho foi utilizar o meu

1.4 ACTIVIDADE DE DEVELOPER – PROJECTO ITELEMETRY


18

conhecimento para que, como membro da equipa Scrum do iTelemetry, conseguisse cumprir os objectivos

definidos para cada Sprint, apresentando iterativamente novas funcionalidades desenvolvidas.

1.4.2 TRABALHO REALIZADO

Como Developer realizei as seguintes actividades junto da equipa iTelemetry:

- Implementação da gestão de elementos no Módulo de Estados da aplicação BackOffice

- Refactoring sobre implementações existentes de MVP que não estavam de acordo com o padrão

- Discutido e elaboradas as convenções de uso de excepções

- Discutido e elaborada a convenção do interface dos retornos da fachada do negócio.

- Criação de um dicionário de Excepções

- Criação do conhecimento sobre Periodicidades das unidades

- Prototipagem do módulo de estados do BackOffice

- Implementação da página de pesquisa de unidades por estados de comunicação

- Prototipagem das fontes de dados de elementos (relação entre propriedades elementos e dados adquiridos)

- Implementação da página de pesquisa de dados de unidades

- Elaboração do plano de testes para a aplicação BackOffice

- Integração da equipa iWaterWeb na plataforma, para o desenvolvimento de uma aplicação Web.

- Reformulação do serviço de dados

- Implementação da interpretação de mensagens protocolares da ISA

- Reformulada integração com iCenter para padrão Plug-In

- Elaboração de protótipo para comparação de desempenho entre modelos de dados

- Elaboração de protótipo para verificar o uso de Bing Maps para mostrar conteúdo georreferenciado

- Elaborados testes unitários para os desenvolvimentos já implementados.

- Refactoring do acesso à camada de negócios em pedidos das aplicações Web. Melhorado o tempos de resposta

do servidor.


19

- Planeado alterações necessárias à implementação dos Presenters das aplicações Web de modo a melhorar o

tempo de resposta do servidor de aplicações Web.


20

2 A METODOLOGIA SCRUM

O Scrum é uma metodologia iterativa e incremental direccionada para o desenvolvimento de software, embora

também possa ser aplicada na gestão de projectos em geral. (1)

A metodologia Scrum define um conjunto de actividades, regras, artefactos e papéis. Essencialmente, a

metodologia define as actividades a realizar durante as iterações do projecto, onde os intervenientes assumem

papéis com responsabilidades específicas, utilizando determinados artefactos durante as actividades. (2)

A metodologia Scrum, aplicada a equipas pequenas, possibilita a criação de equipas independentes, responsáveis

supremos sobre os seus desenvolvimentos, trabalhando em equipa no mesmo espaço de trabalho de modo a

promover a comunicação verbal e directa entre todos os membros da equipa.

Um dos princípios principais do Scrum é o reconhecimento da mudança. (1) Ou seja, as mudanças podem

acontecer a qualquer altura (mudança das necessidades do cliente, mudança dos requisitos do cliente entre outros)

e a equipa Scrum tem de conseguir responder a estas mudanças.

O Scrum, sendo utilizado por uma equipa pequena onde todos os elementos devem conseguir fazer todas as tarefas

necessárias de modo iterativo de acordo com a evolução dos requisito é uma metodologia ágil.

O conceito de metodologia ágil foi introduzido no Agile Manifesto (3) que é um artefacto histórico que resultou da

reunião de vários software developers na discussão de uma melhor maneira de criar software.

Figura 3 Agile Manifesto

2.1 RESUMO

2.2 SCRUM FRAMEWORK

O Scrum funciona como um processo it

Cada uma das iterações é denominada

conjunto de tarefas que tem a fazer (

(Product Backlog) estejam prontas no final da iteração. Diariamente, a equipa reúne para conhecer o progresso da

iteração. (2)

Visualmente o Scrum é apresentado na

Para pôr em prática a metodologia Scrum são necessários os papéis indicados neste capítulo. As equipas de Scrum

são pequenas, tipicamente entre 5 a 9 elementos podendo um elemento da equipa assumir mais que u

que o Scrum define. (1)

O importante é que a pessoa que assume um papel faça o trabalho esperado do seu papel.

2.3.1 SCRUM MASTER

O Scrum Master é o responsável por assegurar o correcto funcionamento do

O Scrum Master conhece as regras da metodologia, faz com que os restantes membros da equipa cumpram com as

regras e tem um papel de facilitador. Ele é responsável por fazer com que a equipa trabalhe do modo mais eficiente

possível removendo obstáculos que obstruam a t

responsável pela adopção de uma prática e filosofia importantíssima no Scrum: a equipa é auto

sozinha.

2.3 PAPÉIS

SSccrruumm AAddvviissoor

O Scrum funciona como um processo iterativo, com iterações típicas entre 2 a 4 semanas.

é denominada Sprint, e têm início com uma reunião onde se uma equipa planeia um

conjunto de tarefas que tem a fazer (Sprint Backlog) para que algumas das funcionalidades do produto

) estejam prontas no final da iteração. Diariamente, a equipa reúne para conhecer o progresso da

é apresentado na Figura 4.

Figura 4 Overview da Framework Scrum


são pequenas, tipicamente entre 5 a 9 elementos podendo um elemento da equipa assumir mais que u


é o responsável por assegurar o correcto funcionamento do Scrum.

er conhece as regras da metodologia, faz com que os restantes membros da equipa cumpram com as


possível removendo obstáculos que obstruam a trabalho da equipa. Ainda como facilitador, o Scrum Master é

responsável pela adopção de uma prática e filosofia importantíssima no Scrum: a equipa é auto

orr && iiTTeelleemmeettrryy DDeevveellooppeerr

21

es típicas entre 2 a 4 semanas.

, e têm início com uma reunião onde se uma equipa planeia um

) para que algumas das funcionalidades do produto final

) estejam prontas no final da iteração. Diariamente, a equipa reúne para conhecer o progresso da


são pequenas, tipicamente entre 5 a 9 elementos podendo um elemento da equipa assumir mais que um dos papéis


er conhece as regras da metodologia, faz com que os restantes membros da equipa cumpram com as


rabalho da equipa. Ainda como facilitador, o Scrum Master é

responsável pela adopção de uma prática e filosofia importantíssima no Scrum: a equipa é auto-suficiente e gere-se


22

Existe apenas um Scrum Master por equipa.

2.3.2 PRODUCT OWNER

O Product Owner é uma ponte entre o cliente e a equipa e é responsável por gerir o crescimento do produto a

desenvolver. O Product Owner sabe que funcionalidades do produto são mais importantes e quais representam

maior valor. Deste modo, o Product Owner tem como responsabilidade garantir que o produto seja desenvolvido

com as funcionalidades certas na altura certa de modo a que o produto desenvolvido cresça em valor.

O Producy Owner é uma figura presente, estando sempre disponível para acompanhar, corrigir e esclarecer o

trabalho que a equipa realiza durante as iterações do produto - Sprint.

Existe apenas um Product Owner por equipa.

2.3.3 TEAM MEMBER

Um Team Member tem a responsabilidade de criar o produto e desenvolver as funcionalidades que o Product

Owner define.

Team Members são ‘cross-funtional’ ou seja, estes são capazes de executar qualquer tarefa necessária para que as

funcionalidades sejam feitas e prontas a entregar no final de uma Sprint. Os membros da equipa têm como

responsabilidade gerir o seu trabalho de forma autónoma de modo a conseguirem adicionar ao produto as

funcionalidades que estão no Sprint Backlog.

2.3.4 PIGS & CHICKENS

Na metodologia Scrum, as pessoas envolvidas num projecto de desenvolvimento de software podem ser

distinguidas entre quem está envolvido (Chickens) e quem está comprometido (Pigs). (2)

Figura 5 Compromisso vs Envolvimento


23

As regras e práticas do Scrum guiam uma equipa que está comprometida, “protegendo-a” das pessoas que estão

envolvidas.

Figura 6 Protecção da equipa

As actividades definidas pelo Scrum são explicadas nesta secção.

2.4.1 SPRINT PLANNING

A actividade tem como objectivo definir as funcionalidades que vão ser adicionadas ao produto na Sprint que está

a ter início.

A Sprint Planning envolve o Product Owner e a equipa. O objectivo é conversar com a equipa de modo a que o

Product Owner saiba o que a equipa consegue fazer (tendo em atenção o risco e necessidades arquitecturais) das

funcionalidades em falta (items existentes no Product Backlog). O Product Owner, sabendo o tempo que a equipa

demora a realizar cada um dos items do Product Backlog, decide as funcionalidades que a equipa irá implementar

prioritizando cada uma das funcionalidades.

Esta decisão é tomada pelo Product Owner de modo a maximizar o valor acrescentado ao produto. Após tomada a

decisão pelo Product Owner sobre os items que a equipa vai trabalhar, a equipa elabora uma lista de tarefas

necessárias que os vai guiar na implementação das funcionalidades escolhidas – Sprint Backlog. Com o Sprint

Backlog elaborado, a equipa começa a trabalhar as funcionalidades. (2)

No final da reunião, a equipa tem um Sprint Backlog elaborado para gerir o seu trabalho e dar início à actividade

Sprint.

2.4 ACTIVIDADES


24

2.4.2 DAILY SCRUM MEETING

A Daily Scrum Meeting é uma reunião rápida (cerca de 15 min.), que tem lugar todos os dias à mesma hora onde a

equipa se reúne, de pé, para se sincronizar.

A actividade implica que todos os membros respondam a 3 perguntas (2):

• O que fizeste desde a última reunião?

• O que vais fazer até à próxima reunião?

• O que te impede de trabalhar o mais eficientemente possível?

É importante que a equipa responda às perguntas dentro do âmbito do projecto, pois os ouvintes estão na reunião

para saber como o desenvolvimento progrediu ao invés de saber pormenores que não influenciam directamente no

progresso do desenvolvimento. Com estas 3 perguntas e a análise do Burndown Chart (onde se consegue ver o

tempo estimado contra o tempo real usado para realizar as tarefas da Sprint) a equipa sabe o trabalho que ainda

falta realizar e a evolução que o produto teve diariamente. Para além da equipa saber o estado do desenvolvimento,

o Scrum Master tem conhecimentos sobre o que impede a equipa de trabalhar o mais eficientemente possível

podendo remover os obstáculos que vão sendo identificados.

2.4.3 SPRINT

A Sprint é o período de tempo que a equipa tem desde o Sprint Planning até à revisão para tornar os Product

Backlogs em funcionalidades no produto.

Por norma, Sprints têm a duração de 2 semanas a 4 semanas.

Durante a Sprint, a equipa tem de gerir o seu Sprint Backlog e Burndown Chart de modo a implementar as

funcionalidades escolhidas no início da Sprint. Diariamente, a equipa reúne-se para fazer a Daily Scrum Meeting.

Durante a Sprint, a equipa tem a responsabilidade de manter o Sprint Backlog actualizado (identificando o

progresso das tarefas) e o Burndown Chart (identificando o tempo esperado para dar os desenvolvimentos como

terminados contra o tempo disponível).

2.4.4 SPRINT RETROSPECTIVE

A Sprint Retrospective é uma reunião curta que decorre no final da Sprint com o objectivo permitir que a equipa

analise e melhore o seu desempenho.

Durante a reunião os membros da equipa enumeram os problemas identificados e discutem as soluções para estes

problemas. As soluções encontradas pela equipa são postas em prática na Sprint seguinte. Deste modo, a equipa

Scrum segue a filosofia ‘Inspect and Adapt’, ícone das metodologias ágeis.


25

2.4.5 SPRINT REVIEW

A Sprint Review é uma reunião que ocorre no fim de cada Sprint onde a equipa mostra publicamente o trabalho

desenvolvido, antes de dar início a uma nova Sprint com a Sprint Planning.

Com audiência aberta, qualquer pessoa é livre de assistir à demonstração das funcionalidades desenvolvidas. A

actividade torna o trabalho da equipa visível e permite a comunicação entre os stakeholders e a equipa que

desenvolve o produto.

O Scrum define 3 artefactos para a sua execução, são eles o Product Backlog, Sprint Backlog e Burndown Chart.

Estes artefactos são criados e mantidos pelos membros da equipa de Scrum durante as actividades do Scrum.

2.5.1 PRODUCT BACKLOG

Um Product Backlog é uma wishlist: uma lista de funcionalidades, equivalente a requisitos esperados para o

produto que se está a desenvolver.

Cada funcionalidade é denominada por Product Backlog Item e tem geralmente os seguintes atributos: prioridade,

valor, tempo estimado de implementação. Este artefacto é gerido pelo Product Owner, sendo normalmente escrito

sob a forma de User Stories (formato ágil para a representação de um requisito): “Como X, faço Y e acontece Z”.

Estes itens normalmente são escritos no formato de valor, ao invés de técnico.

Ex: “Como administrador, devo poder alterar as palavras-chave dos utilizadores do sistema”.

A Figura 7 é um exemplo de um Product Backlog.

Descrição Prioridade Estimativa

Como Administrador, devo poder alterar as palavras-

chave dos utilizadores do sistema

Alta 45

Os utilizadores devem ter uma foto de perfil. Alta 85

Os utilizadores devem poder convidar 1 amigo por

semana para usufruir do serviço

Alta 60

Um utilizador deve conseguir substituir a sua foto de

perfil por qualquer foto usada anteriormente

Media 120

Figura 7 Product Backlog

2.5 ARTEFACTOS


26

Este artefacto é actualizado regularmente pelo Product Owner, transparecendo as funcionalidades que já foram

implementadas e as que estão por implementar.

2.5.2 SPRINT BACKLOG

O Sprint Backlog é o artefacto utilizado pela equipa para gerir o trabalho realizado durante uma Sprint.

O Sprint Backlog é um conjunto de Sprint Backlog items, que são tarefas a realizar de cariz técnico. As tarefas são

acompanhadas de um tempo estimado até à sua conclusão e de uma prioridade, podendo ser realizadas por

qualquer membro da equipa. As tarefas são criadas pela equipa para representar o trabalho e tempo necessários

para implementar qualquer Product Backlog item. Assim, pode haver várias tarefas para dar uma funcionalidade

(Product Backlog item) como concluída. O Sprint Backlog é mantido pela equipa ao longo da Sprint, estando esta

responsável por actualizar os Sprint Backlog items de modo a que a equipa tenha noção do tempo que necessita

para dar término à Sprint.

Este artefacto é público e visível por todas as pessoas, mesmo fora da equipa. Existem variadas formas de manter

um Sprint Backlog, devido ao uso de diferentes ferramentas. O essencial, é que a equipa tenha uma lista de tarefas

devidamente prioritizadas e actualizadas com o tempo esperado para a sua conclusão.

Figura 8 Sprint Backlog da ferramenta Version1


27

Figura 9 Sprint Backlog da ferramenta JIRA

2.5.3 BURNDOWN CHART

Este artefacto consiste num gráfico com indicação do tempo necessário para a conclusão das tarefas ao longo da

Sprint. Neste existem duas linhas: o tempo restante ideal e o tempo restante real.


28

Figura 10 Burndown Chart

A qualquer altura da Sprint é possível perceber a situação do desenvolvimento, apenas olhando para o gráfico.

Ex: No dia 5, a equipa estava atrasada em relação ao esperado no dia 5. No dia 7, esta já tinha concluído mais

trabalho do que o estimado para o dia 7.


29

3 O SCRUM NA ISA

Neste capítulo é explicado como é que o Scrum foi introduzido na ISA nas equipas de desenvolvimento de

software.

É abordado o modo como o departamento de software funcionava, de modo a perceber como o Scrum foi

introduzido e aceite como metodologia de desenvolvimento. É também especificado como as equipas utilizam o

Scrum.

É de notar que o departamento de software tem sofrido grandes alterações no seu modo de funcionamento

recentemente, melhorando bastante o seu desempenho em relação a anos anteriores.

Este capítulo descreve também como foram elaboradas as análises de conformidade da implementação do Scrum

pela equipa iTelemetry com as regras do Scrum e resultados da primeira avaliação realizada. O capítulo descreve

também como foi elaborado um conjunto de métricas para avaliar as práticas do Scrum de modo a complementar a

conformidade das regras, juntamente com os seus resultados.

3.1.1 EQUIPAS

Os elementos da equipa de software por norma encontravam-se alocados a vários projectos ao mesmo tempo,

alternando de equipas e projectos com frequência.

3.1.2 METODOLOGIAS

Não existia na ISA nenhuma metodologia de desenvolvimento de software definida.

Os desenvolvimentos de software por vezes eram efectuados de modo semelhante a um Waterfall. Nestes casos,

existia uma definição inicial do produto após uma negociação de requisitos, juntamente com o desenvolvimento e

manutenção do software.

3.1.3 PROBLEMAS IDENTIFICADOS

O funcionamento antigo do departamento, apesar de apresentar produtos e soluções completas, apresentava

problemas.

Esses problemas por norma recaíam sobre os mesmos tópicos. Os requisitos dos desenvolvimentos não se

encontravam bem definidos, existindo ambiguidade e margem para dúvidas nas interpretações; Os

desenvolvimentos eram frequentemente solicitados ‘para ontem’ ou com prazos apertados; Os recursos existentes

encontravam-se em múltiplos projectos.

3.1 SITUAÇÃO ANTERIOR AO SCRUM


30

3.2 A ADOPÇÃO DO SCRUM

3.2.1 I NTRODUÇÃO DO SCRUM

A introdução do Scrum é o resultado de um esforço para melhorar o departamento de software.

Para colmatar os problema identificados, seria necessário que fosse utilizado uma metodologia que permitisse a

entrega regular de software de modo a proporcionar mais visibilidade sobre os desenvolvimentos efectuados e

reagindo melhor alterações e mudanças de planos.

A ideia do uso de Scrum foi colocada por uma equipa e a sua aceitação teve lugar devido às necessidades de

encontrar uma metodologia com a flexibilidade necessária. A ‘moda’ do Scrum teve também alguma influência na

aceitação. A equipa em questão pesquisou a metodologia, aprendeu a metodologia sozinha e colocou-a em prática

num projecto-piloto. Devido aos bons resultados obtidos, a adopção do Scrum tem vindo a ser tomada pelas

actuais equipas de software.

3.2.2 I NTEGRAÇÃO DE NOVOS ELEMENTOS NO SCRUM

A integração de novos elementos em equipas de Scrum é feita pela equipa em si.

Caso o novo elemento não conheça a metodologia, é responsabilidade da equipa dar a conhecer a equipa e educar

o elemento novo nos seus princípios e regras. O Scrum não se encontra documentado, sendo a integração feita

essencialmente de modo verbal, acompanhada pela equipa.

3.2.3 FERRAMENTAS USADAS

Para por a metodologia em prática é utilizado uma de duas ferramentas.

Estas ferramentas auxiliam as equipas na gestão dos Product Backlog items, Sprint Backlogs e BurndownChart:

• Version1 é um software de gestão para Scrum. Utiliza uma interface Web, permitindo essencialmente o

agendamento de Sprints, gestão de Product Backlog items e defects, visualização de taskboards,

testboard e planning boards com possibilidade de drag n drop para uso fácil.


31

Figura 11 ScreenShot Ferramenta Version1

• Folha Excel para definir os Product Backlog items, Sprint Backlogs e manter um registo diário sobre o

trabalho que falta. Cada Sprint dá origem a uma folha de cálculo para um Sprint Backlog e outra para a

revisão da Sprint.

Figura 12 Folha de Calculo para gestão Scrum


32

• JIRA é um software que permite a gerir e acompanhar projectos de software. A ferramenta tem um

interface Web onde é possível fazer drag n drop das tarefas, stories etc. Permite visualizar uma

taskboard, planning board, progresso de projecto e Burndown Charts.

Figura 13 Screenshot da ferramenta JIRA

O uso de uma das ferramentas é obrigatório para apresentar o resultado final de cada Sprint. De outro modo, os

desenvolvimentos não se encontram em conformidade com o Sistema de Qualidade da Concepção e

Desenvolvimento da ISA.

3.2.4 I NDEPENDÊNCIA DAS EQUIPAS DE SCRUM

As equipas de Scrum actuais possuem membros que são capazes de realizar qualquer tarefa de cariz tecnológico

necessário para concluir os seus objectivos.

Apesar de os elementos terem uma especialidade numa determinada área, ou de dominarem melhor uma certa

tecnologia, qualquer membro consegue actualmente realizar qualquer tarefa no âmbito do projecto onde está

inserido. As equipas apenas não são totalmente dependentes em termos arquitecturais das soluções tecnológicas.

Questões onde são envolvidas questões de hardware desenvolvido pela ISA ou que usem integrações de serviços e

soluções variados são tomadas em conjunto com as devidas entidades.

3.2.5 RESULTADOS DA INTRODUÇÃO DO SCRUM

Com a implementação de Scrum na ISA, as solicitações de desenvolvimentos, correcção de bugs e manutenções

tornaram-se mais fáceis de gerir.

Com o conceito de Sprints e prioridades de desenvolvimento, tem-se verificado efectivamente que as equipas de

software são bastante menos interrompidas, e as solicitações são mais selectas e elaboradas. Situações como


33

requisitos menos bem elaborados têm sido menos comuns dado que existe mais foco na colaboração e

comunicação directa.

Com a metodologia, existe a noção de que as solicitações não ficam prontas imediatamente, cortando em muito as

interrupções e reduzindo a entropia nos desenvolvimentos.

A alocação do mesmo recurso a vários projectos tem sido bastante reduzida.

De forma a ter-se uma visão mais clara da forma como as regras do Scrum estavam a ser seguidas, realizou-se uma

análise de conformidade com as regras do Scrum (4).

3.3.1 MÉTODO UTILIZADO

Este método de avaliação tinha um objectivo: verificar se cada regra do Scrum estava a ser seguida. Com este

objectivo em mente, foram elaborados critérios para as várias regras do Scrum, organizados por actividade.

Figura 14 Relação dentre Actividades, Regras e Critérios de Avaliação

Cada critério é avaliado como Sim ou Não. Por exemplo, para um critério: “As reuniões diárias são feitas de pé?”

apenas é possível avaliar o critério como “Sim” ou “Não”. Não é possível haver um meio-termo.

O guia de avaliação das regras Scrum (5)é um documento que tem como objectivo guiar um colaborador da ISA,

ou qualquer outra pessoa que avalia uma implementação Scrum em inferir se as regras estão a ser seguidas ou não.

3.3 CONFORMIDADE COM REGRAS

Critérios de Conformidade Scrum


34

Cada regra é acompanhada por uma justificação da sua existência dentro do Scrum (2), para melhor compreender a

necessidade da regra.

As regras no documento em questão estão apresentadas no documento no formato apresentado na Figura 15:

Figura 15 Quadro de Descrição da Regra

A Figura 16 exemplifica uma regra devidamente justificada dentro do Scrum, com os seus critérios:

Figura 16 Exemplo de uma Regra Daily Scrum Meeting

Para pôr em prática a avaliação da conformidade com as regras Scrum, foi necessário guardar de algum modo os

resultados das avaliações dos critérios.

Folha de Calculo para Critérios de Conformidade Scrum


35

Optou-se por utilizar uma folha Excel para guardar estes resultados por Sprint. Deste modo, é possível persistir os

resultados das várias avaliações e visualizar os resultados das avaliações por Sprint (coluna). Os critérios das

avaliações estão agrupados por actividade do Scrum.

O aspecto padrão da folha da Excel, onde se encontram agrupados os critérios das actividades é o seguinte:

Figura 17 Excerto dos Critérios da Daily Scrum Meeting da equipa iTelemetry

3.3.2 RESULTADOS

Os resultados apresentados dizem respeito à avaliação feita na implementação do Scrum pela equipa iTelemetry

(4).

Este capítulo resume os resultados do primeiro trabalho da primeira análise, que se encontra detalhado num

artefacto criado durante o estágio e que serve de base à primeira intervenção do capítulo Melhorias Introduzidas ao

Scrum da ISA.

A implementação tem falhas. Não são realizadas as actividades de Sprint Review e Sprint Retroespective.

As Daily Scrum Meetings estendiam-se por muito mais que 15 minutos, chegando a atingir picos de 50 minutos.

As Daily Scrum Meetings eram aproveitadas para realizar trabalho que não fazia parte da Daily Scrum Meeting

como actualização do Sprint Backlog, estimação dos tempos em falta para acabar cada tarefa e discussão de

questões técnicas.

As Sprint Planning Meetings apresentavam problemas na condução da reunião. A Sprint Planning Meeting era

passada a discutir questões técnicas em redor de uma funcionalidade esperada que nem sempre reflectiam items do

Product Backlog. A Sprint Planning Meeting não tinha o focus correcto: O Product Owner não tentava perceber o

que a equipa conseguia fazer de cada Product Backlog item para escolher os Product Backlog items a trabalhar na

Sprint que estava a ter início.

A Sprint também apresentava problemas. Os Sprint Backlog items não eram públicos e visíveis. Frequentemente,

os items não eram “acabados”. A definição de “done” não era sempre respeitada nem estabelecida.

A avaliação de práticas foi elaborada para conseguir verificar se as práticas Scrum estavam a ser seguidas.

3.4 AVALIAÇÃO DAS PRÁTICAS DE SCRUM


36

Enquanto o comparativo de regras permite verificar se as regras do Scrum são cumpridas, a avaliação das práticas

verifica se o Scrum funciona como um todo avaliando os hábitos de uma equipa.

A avaliação das práticas complementa a avaliação das regras, envolvendo por exemplo noções de hábitos de

equipa, práticas de engenharia que não se encontram nas regras.


Para conseguir verificar as práticas de Scrum, foi definido que seriam estudadas métricas.

Após algum tempo a pesquisar sobre métricas, foram elaboradas algumas métricas (5). No entanto, devido à

elaborada avaliação, estas foram abandonadas. Devido à necessidade de avaliar a eficácia das práticas Scrum

optou-se por utilizar as métricas definidas pela Scrum Alliance (6). A Scrum Alliance sugeria um conjunto de

métricas para o Scrum e métricas para o projecto onde o Scrum era usado. Estas métricas eram algo genéricas, e

foi necessário criar um guia para auxiliar a aplicação das métricas no âmbito da empresa. Neste sentido, atribuiu-se

significado na interpretação das métricas no contexto da ISA.

Para se poder definir uma métrica, é necessário perceber bem os seus requisitos e o que significa. Uma métrica é

mais do que apenas um valor obtido; as métricas existem para que se perceba o estado de uma realidade

pontualmente, de modo a perceber progresso, regressão ou estagnação. (6)As métricas servem para ajudar a tomar

decisões sobre algo. No caso do Scrum, uma métrica ajudará a tomar decisões sobre como melhorar determinados

aspectos da implementação do Scrum. No caso de um projecto, as métricas servirão para saber que decisões tomar

de acordo com as informações que se têm.

Assim, todas as métricas devem ser:

• Significativas - As métricas devem contemplar informação que efectivamente interessa a quem as recolhe;

• Actuais - As decisões têm de ser aplicada sobre indicadores mais recentes possível. Interessa que valores das

métricas estejam actualizados quando são utilizados.

• Não Obstrutivas - A utilização da métrica e a sua recolha não deve introduzir mudanças ou necessidades de

aprendizagem.

• Empíricas - As métricas devem ser fáceis de avaliar.

• Accionáveis - Métricas devem servir para fomentar discussões sobre como melhorar algo. Uma métrica deve

servir de base para tomada de decisões.

Deve ser medido o necessário e nada mais.

Conceito de Métricas

Avaliação Métricas do Processo


37

Com a contextualização das métricas na realidade da ISA e designando um método de avaliação de cada métrica,

elaborou-se um documento (5) onde se encontram explicadas as métricas.

Este documento serve de guia para que colaboradores da ISA possam ler e compreender como medir as suas

práticas de Scrum. Para além de fazer com que um colaborador saiba como atingir uma melhor ‘performance’ com

as práticas Scrum, o documento guia o colaborador no preenchimento de um outro documento onde são guardados

os resultados da avaliação das métricas.

Figura 18 Formulação Genérica de uma Métrica do Processo

O documento contém uma entrada semelhante à imagem para todas as métricas sugeridas pela Scrum Alliance,

conforme especificado na Figura 18. Às métricas definidas pela Scrum Alliance foi adicionada a justificação da

existência da métrica, bem como o modo de medição e a descrição das condições verificadas para a atribuição da

menor e da maior pontuação no âmbito da ISA, tal como exemplificado na Figura 19.


38

Figura 19 Exemplo de uma métrica da equipa

A maior e melhor pontuação que se pode obter numa métrica é o valor 5.

A menor e pior pontuação que se pode obter numa métrica é o valor 0.

Os resultados das avaliações das métricas do Scrum foram guardas numa folha Excel.

A folha de cálculo Excel permite organizar e visualizar os resultados das avaliações das métricas.

Figura 20 Excerto da folha de cálculo das avaliações do Processo

Tal como se pode verificar pelo na Figura 20, é possível visualizar num gráfico Excel o progresso das diferentes

métricas por Sprint.

Folha de Calculo Métricas Processo


39

3.4.2 RESULTADOS

Os resultados apresentados tiveram como base a avaliação da equipa iTelemetry. Estes resultados foram utilizados

para fundamentar melhorias introduzidas no capítulo Melhorias Introduzidas ao Scrum da ISA.

Resumidamente e em traços gerais, Product Owner foi avaliado pelas métricas com um desempenho a 0. As

métricas de planeamento tiveram uma pontuação aceitável com média 3. As métricas de agendamento revelaram

problemas no agendamento do Sprint Planning e Sprint Review. As métricas de Scrum revelaram que a equipa

deve melhorar a auto-disciplina no uso do Scrum. As métricas para a equipa obtiveram pontuação máxima excepto

no uso do Burndown Chart ao longo da Sprint. As métricas de reporting apresentaram bons resultados, tendo uma

pontuação mais fraca na actualização do Product Backlog. As métricas de Engineering Practices & Infraestruture

revelaram a falta de métricas medir a qualidade dos desenvolvimentos. Revelaram também a falta dos testes

automáticos de aceitação. As métricas de Engineering Practices & Infraestructure revelaram também que a equipa

tem boas práticas de trabalho.

A Scrum Alliance sugere para além das métricas para o Scrum um conjunto de métricas para o projecto em que a

equipa trabalha. (7)

Neste sentido, também foram elaboradas métricas para medir o estado do desenvolvimento dos projectos:

indicadores de qualidade.


Os indicadores de qualidade são valores que visam medir o estado do Projecto criado sob alguns aspectos. A

elaboração dos indicadores define que dados recolher, bem como a razão pela qual estes são recolhidos e os

significados quando estes estão num valor considerado alto ou baixo. Estes são representados genericamente na

Figura 21 e concretizados numa em indicadores como o da Figura 22:

Figura 21 Formato de um indicador de qualidade

3.5 AVALIAÇÃO DO PROJECTO


40

Figura 22 Exemplo de um Indicador de qualidade


41

4 M ELHORIAS I NTRODUZIDAS AO SCRUM DA ISA

Este capítulo contém informação sobre as mudanças que foram introduzidas no Scrum adoptado pela ISA.

As mudanças foram introduzidas após uma análise de dados recolhidos dos métodos de avaliação de conformidade

com as regras de Scrum e métricas. A decisão sobre que acções tomar face às sugestões dadas foi sempre tomada

pelo Scrum Master em reuniões informais.

Visto que, de acordo com os resultados das avaliações, existia muito trabalho por fazer para melhorar as práticas

de Scrum (ex: mudança de local para realizar a Daily Scrum Meeting, realizar a Daily Scrum Meeting à mesma

hora, tornar público o Sprint Backlog e o Burndown Chart, realizar Sprint Review e Sprint Retroespective entre

outros), optou-se por elaborar, em alturas diferentes, pequenas acções. Assim, os elementos da equipa não teriam

um esforço de adaptação tão grande, reduzindo a probabilidade de uma eventual resistência à mudança.

A primeira proposta de melhoria foi elaborada após a primeira análise de conformidade com as regras de Scrum

(4). Foi feita uma análise à implementação do Scrum pela equipa iTelemetry e identificados alguns problemas e

apresentadas sugestões para os resolver.

São a seguir apresentados os resultados por actividade

4.1.1 SPRINT PLANNING MEETING

Os dados apresentados foram recolhidos ao presenciar as Sprint Planning Meetings.

4.1 PRIMEIRA I NTERVENÇÃO

Problemas Identificados


42

Figura 23 Resultados da avaliação das regras Sprint Planning Sprint

De acordo com os resultados apresentados na Figura 23, identificaram-se essencialmente os seguintes problemas:

• Não havia distinção entre as 2 partes distintas da Sprint Planning Meeting.

• Não havia uma clara selecção dos Product Backlog items a trabalhar na Sprint.

• O Product Owner tinha grandes responsabilidades técnicas arquitecturais dentro do departamento,

focando a discussão da Sprint Planning Meeting em questões técnicas sobre implementações.

• A Sprint Planning Meeting não era usada para se perceber o que é que conseguia fazer em cada Product

Backlog item, para decidir os items a implementar.

• As estimativas sobre os Sprint Backlogs eram feitas através de uma média das estimativas de cada

elemento.

Face a estes problemas, foram sugeridas as seguintes alterações:

• Educar os participantes para o correcto funcionamento da Sprint Planning Meeting

• Separar a Sprint Planning Meeting em duas partes distintas

• Fomentar a moderação da Sprint Planning Meeting por todos os intervenientes

• Utilizar outro método de estimativa

Sugestões


43

Das acções sugeridas, começou-se a separar a Sprint Planning em 2 partes distintas.

Durante as Sprints seguintes, a Sprint Planning Meeting começou a ser separada. No entanto, durante as reuniões

de início de Sprint, a primeira parte continuou a ser alvo de grande discussão técnica com o Product Owner.

Começou-se ainda a utilizar Planing Poker para fazer estimativas.


Estes dados foram recolhidos durante as Daily Scrum Meetings da equipa iTelemetry, reflectindo uma avaliação

geral de todas as reuniões que ocorreram desde a entrada na equipa até à elaboração do comparativo.

Figura 24 Resultados das Daily Scrum Meetings

De acordo com os resultados da análise realizada durante as primeiras Sprints do estágio, foi verificado que a

actividade não cumpria a grande maioria das regras de Scrum, conforme verificado na Figura 24.

Os principais problemas identificados na conformidade com as regras são:

Acções Tomadas

Resultados



44

• As reuniões prolongavam-se entre ~25 a 50 minutos.

• As reuniões eram aproveitadas para actualizar o Sprint Backlog enquanto cada membro fazia o seu report.

• As reuniões envolviam bastantes discussões de problemas técnicos.

A falta de salas para fazer a Daily Scrum Meeting revelou-se também um problema.

Face a estes problemas, foram sugeridas as seguintes acções:

• Aumentar o espírito de compromisso com a Daily Scrum Meeting

• Iniciar a Daily Scrum Meeting à mesma hora no mesmo local

• Preparar as respostas antes de se ir para a Daily Scrum Meeting

• Envolver o Product Owner na Daily Scrum Meeting

Foram tomadas as seguintes decisões para melhorar as reuniões diárias:

• Mudar o local onde se realiza a Daily Scrum Meeting.

• Dar início a Daily Scrum Meeting a uma hora fixa.

• Fazer a Daily Scrum Meeting de pé.

• Deixar de actualizar os Sprint Backlog items na Daily Scrum Meeting

As reuniões começaram a ser curtas, demorando cerca de 5 a 15 minutos.

As reuniões começaram a ser feitas de pé, junto à máquina do café.

Os elementos actualizavam o Sprint Backlog fora da Daily Scrum Meeting.

4.1.3 SPRINT

Os dados da Sprint foram recolhidos durante o decorrer das Sprints das Sprint que foram realizadas desde a minha

entrada na equipa até à elaboração do comparativo. Os resultados representam uma apreciação global da

actividade.

Sugestões

Acções Tomadas

Resultados


45

Figura 25 Resultado da avaliação da Sprint

Apesar do resultado positivo na análise de conformidade com regras desta actividade na Figura 25, foram

identificados os seguintes problemas:

• Falta de visibilidade do Sprint Backlog e do Burndown Chart.

• Inexistência da definição de feito

• Overwork pela equipa no final de Sprints.

• Backlog Items não eram fechados entre Sprints, prolongando-se funcionalidades entre Sprints.

Para corrigir estes problemas, foi sugerido que:

• Os Burndown Charts e Sprint Backlogs se tornassem públicos.

• Fosse claramente definido o conceito de feito.

• Os membros das equipas se aproximassem fisicamente.

Com as sugestões dadas, foi elaborada a definição de feito, e começaram a ser colocados publicamente Burndown

Charts.


Sugestões de Melhoria

Acções Tomadas


46

A definição de feito continuou um conceito pouco usado. Os Sprint Backlog items continuaram a transitar entre

Sprints e os Sprint Backlogs items eram dados como concluídos mesmo sem terem todo o trabalho realizado.

Os Burndown Charts impressos não obtiveram impacto, caindo no esquecimento e passando despercebidos. Os

Burndown Charts eram impressos poucas vezes por Sprint e não chamavam a atenção da equipa nem do

departamento.

4.1.4 SPRINT REVIEW

A Sprint review não era praticada. Face a esta realidade, foi sugerido que se começasse a realizar a actividade. Não

foi tomada nenhuma acção.

4.1.5 SPRINT RETROESPECTIVE

A Sprint Retroespective não era praticada. Deste modo, foi sugerido que se começasse a realizar a actividade.

O segundo conjunto de melhorias sugeridas foi efectuado após a primeira sugestão em meados de Abril conforme

mostrado na Figura 2 (9). A proposta foi elaborada com base nos resultados da avaliação do comparativo

elaborado em Abril.

Na Figura 26 são apresentados os resultados das avaliações na primeira análise (à esquerda) e da segunda análise

(à direita), para que se possam verificar como a conformidade com as regras do Scrum evoluiu.

4.2.1 SPRINT PLANNING

Resultados

4.2 SEGUNDA I NTERVENÇÃO



47

Figura 26 Extracto da Conformidade da Actividade Sprint

Na Sprint em questão houve uma enorme pressão na equipa. Essencialmente, era necessário entregar o produto e

colocá-lo em produção. Deste modo, foram identificados os seguintes problemas:

• Não houve envolvimento no início da Sprint do Product Owner, sendo substituído pelo Scrum Master.

• A decisão dos items a trabalhar já estava tomada antes do Sprint.

Foi sugerido envolver o Product Owner na actividade e mais no projecto.

Foram feitas tentativas de envolvimento do Product Owner nas actividades. Foi consultado uma segunda pessoa,

com grande responsabilidade sobre o departamento para tomar decisões quando o Product Owner não estava

disponível para a equipa.

O Scrum Master teve de substituir o Product Owner nos inícios de Sprint, consultando o Product Owner quando

este se encontrava disponível.


Acções Tomadas

Resultados


48


Figura 27 Extracto da Conformidade da actividade Daily Scrum Meeting

As reuniões diárias foram feitas perto da máquina do café, onde a equipa tinha algum espaço para se colocar de pé

e realizar a Daily Scrum Meeting. Com este hábito, existiam ainda os seguintes problemas:

• A Daily Scrum Meeting continuava a ser alvo de discussão técnica.

• Por vezes, as 3 perguntas não eram todas respondidas pelos elementos.

• A Daily Scrum Meeting continuava sem hora de início fixa.

Foi sugerido marcar uma hora para dar início à Daily Scrum Meeting, de modo a que todos os elementos

pudessem previamente preparar o que responder.

Foi sugerido que os elementos apenas respondessem às 3 perguntas da Daily Scrum Meeting.

Para melhorar estes pontos, foi estabelecido que a equipa faria as Daily Scrum Meetings às 9h30.

Problemas identificados


Acções Tomadas


49

A tentativa de reunir todos os dias à mesma hora fracassou devido à hora de entrada flexível dos colaboradores e

pela necessidade dos membros das equipas serem necessários para resolver problemas urgentes na empresa.

Os elementos começaram a responder apenas às 3 perguntas, apesar de por vezes o Scrum Master intervir para

manter a ordem. Após todos os membros reportarem era anunciado o fim da Daily Scrum Meeting. A partir daí,

membros que não quisessem participar nas discussões que surgiam após a Daily Scrum Meeting eram livres de o

fazer.

4.2.3 SPRINT

Figura 28 Extracto da conformidade da actividade Sprint

Foram identificados como problemas a grande pressão externa sobre a equipa e o facto de os membros da equipa

frequentemente terem de parar o seu trabalho para resolver problemas que surgiam.

Não foi elaborada nenhuma melhoria para resolver os problemas identificados. No entanto, alguns problemas

teriam sido evitados se em Sprints anteriores os Sprint Backlog items fossem realmente concluídos. Para este fim,

foi sugerido que se começasse a separar o Sprint Backlog melhor, de modo a que estimativas para as tarefas não

fossem superiores a um dia de trabalho.

Resultados



Acções Tomadas


50

Foi decidido se deve evitar que as tarefas no Sprint Backlog tenham mais que 2 dias de trabalho.

Com esta decisão, foi possível criar melhores estimativas e planear melhor o trabalho. Deixou de haver tarefas

genéricas como “Implementar CRUD de Utilizadores” para haver uma tarefa distinta para criação, remoção,

actualização e leitura de utilizadores.

4.2.4 SPRINT REVIEW

A actividade não foi realizada. A sugestão para este problema foi fazer a actividade.

4.2.5 SPRINT RETROSPECTIVE

A actividade continuou sem ser efectuada, e foi sugerido de novo iniciar a actividade de modo a que a equipa pare

e consiga reflectir sobre o que está mal e o que pode ser feito para melhorar.

A actividade começou a ser feita em conjunto após uma outra actividade: revisão de código.

O intuito da junção das actividades foi aproveitar a sala de reuniões reservada para a equipa, de modo a cumprir as

normas da qualidade e aproveitar problemas identificados na revisão de código para identificar pontos a melhorar

na Sprint seguinte.

A terceira proposta de melhoria foi elaborada nos finais de Junho após por em prática o método de avaliação das

métricas do Scrum e ter recolhido e analisado os resultados juntamente com a avaliação da conformidade, no final

do estágio. (10)

4.3.1 PROBLEMAS I DENTIFICADOS

Figura 29 Excerto da avaliação das métricas do Product Owner

Como se pode verificar na Figura 29, o Product Owner tem uma pontuação muito baixa, faltando a contribuição do

Product Owner na equipa Scrum.

Resultados

4.3 TERCEIRA I NTERVENÇÃO


51

Figura 30 Excerto da avaliação das métricas para o planeamento

A Figura 30 indica que o planeamento praticado pela equipa iTelemetry apresenta boas práticas de planeamento,

apesar de poderem ser melhoradas.

Figura 31 Excerto da Avaliação das métricas de Agendamento

O agendamento tem principais problemas em não ser realizada a Sprint Review e por a Sprint Planning Meeting

não ser certa conforme verificado na Figura 31. É adiada com frequência e não envolve o Product Owner.

Figura 32 Excerto da Avaliação das métricas do Processo

Em termos de processo, a Figura 32 mostra que os pontos a melhorar (mais baixos) são a colaboração com o

Product Owner e o cuidado da equipa em seguir o processo e as regras.

Figura 33 Excerto da Avaliação das métricas da Equipa

O problema identificado, de acordo com a Figura 33 foi que a equipa não usa os indicadores do Burndown Chart.


52

Figura 34 Excerto da Avaliação das métricas de Reporto

Segundo a Figura 34, o reporting da equipa em geral é bom, podendo ser melhorado a manutenção e comunicação

do Product Backlog.

Figura 35 Excerto da Avaliação das métricas de Engenharia e Infra-estrutura

Nas práticas de engenharia e infra-estrutura foi identificado que a equipa não tinha qualquer automatização de

testes de aceitação para as aplicações desenvolvidas, de acordo com a Figura 35. Estes eram todos manuais.

4.3.2 SUGESTÕES

As seguintes sugestões de melhoria foram efectuadas para serem aplicadas após o término do estágio. A ideia será

introduzir as melhorias no Scrum de forma faseada, pelo menos uma por Sprint, de modo a resolver os pontos com

pior pontuação nas métricas.

1. Durante duas Sprints, dever-se-á envolver mais o Product Owner de modo que a sua participação na

Sprint planning seja melhorada. O trabalho da equipa deverá manter os artefactos Sprint Backlog e

Burndown Chart públicos e visíveis.

2. Durante uma Sprint dever-se-á iniciar a actividade de Sprint Review. Deverá ser envolvido o Product

Owner na validação dos Product Backlog dados como feitos.

3. Durante duas Sprints, deverá ser introduzido o hábito de consulta do Burndown Chart para tomada de

decisões na equipa. Deverá ser escolhido uma hora e local para realizar as reuniões diárias de Scrum para

que a equipa venha a mais preparada possível para esta e a sinta como uma necessidade.


53

4. Deverá ser fomentado o espírito de compromisso e trabalho de equipa, criando uma repercussão para os

atrasos nas reuniões diárias.


54

5 PROCEDIMENTOS PARA M ELHORIA CONTÍNUA DO SCRUM

O último trabalho realizado na qualidade de Scrum Advisor foi a elaboração de um guião (11) com procedimentos

para orientar e incentivar uma melhoria contínua da metodologia de Scrum adoptada na ISA. Este capítulo define

quais os objectivos deste guião, bem como funcionam as actividades deste.

Os objectivos que se pretendem atingir com a execução deste guião são:

• Fornecer à equipa informação sobre a sua performance no Scrum

• Fomentar uma correcta utilização do Scrum

• Fomentar o conhecimento do Scrum

• Fomentar as práticas do Scrum

O conceito em mente para o guião foi de utilizar os métodos de avaliação elaborados durante o estágio e colocar os

membros das equipas a avaliarem de forma regular o desenrolar dos projectos.

Ao realizar esta actividade, os membros frequentemente farão uma introspectiva sobre o trabalho realizado e

interiorizam os conceitos, práticas e regras do Scrum. Os resultados destas análises são utilizados na Sprint

Retroepective Meeting para servir de base a discussão sobre como melhorar o desempenho da equipa.

5.1 OBJECTIVOS

5.2 CONCEITO

5.3 CICLO DE VIDA DE PROCEDIMENTOS PARA MELHORIA CONTÍNUA DO SCRUM


55

Figura 36 Fluxograma dos procedimentos de melhoria contínua

A Figura 36 mostra o que deve ser feito e quais os inputs e outputs entre as várias actividades. Estes

procedimentos são realizados a cada Sprint.

Existe uma fase de recolha de dados sobre a Sprint que envolve a recolha da conformidade das regras seguidas (1),

a recolha das métricas do Scrum (2) e a recolha dos resultados no projecto desenvolvido (3).

Depois de ter os dados da Sprint em termos de regras, práticas e resultados é elaborado um relatório (4) onde se

verificam os resultados obtidos contra os esperados. Este relatório é utilizado pela equipa durante a Sprint

Retrospective para auxiliar a reflexão e ajuda-la a melhorar.

Caso a equipa decida que se devem mudar os métodos de recolha de dados, estes são mudados (6) para serem

utilizadas mais tarde quando a equipa tiver de fazer uma nova recolha de dados.


56

6 DEVELOPER NO PROJECTO I TELEMETRY

A actividade de developer no projecto iTelemetry foi realizada como membro da equipa iTelemetry. Nesta

qualidade, foi efectuado todo o tipo de trabalhos necessários para alcançar os objectivos de cada Sprint realizada

pela equipa.

Para conseguir alcançar os objectivos das Sprints do iTelemetry foram aplicados conhecimentos sobre a concepção

e desenvolvimento de Software. Especificamente, foram efectuados desenvolvimentos em Entity Framework com

recurso a C#, asp.NET, jQuery, WCF, HTML, CSS, Javascript. Foram efectuados variadas modelações para

exprimir, debater e construir os desenvolvimentos de software (modelos de domínio, diagramas de sequência,

diagramas de classes etc.) e persistência de dados (modelos entidade-relacionamento). Foram também concebidos,

realizados e automatizados testes ao iTelemetry através de C# e NUnit.

A actividade envolveu essencialmente a aplicação prática das várias competências técnicas na concepção,

desenvolvimento e manutenção de software, ocupando cerca de 80% do estágio.

Foi realizado no âmbito do iTelemetry: a implementação da gestão de elementos no Módulo de Estados da

aplicação BackOffice; refactoring sobre implementações existentes de MVP que não estavam de acordo com o

padrão; discutido e elaboradas as convenções de uso de excepções; discutido e elaborada a convenção do interface

dos retornos da fachada do negócio; criação de um dicionário de Excepções; criação do conhecimento sobre

Periodicidades das unidades; prototipagem do módulo de estados do BackOffice; implementação da página de

pesquisa de unidades por estados de comunicação; prototipagem das fontes de dados de elementos (relação entre

propriedades elementos e dados adquiridos); implementação da página de pesquisa de dados de unidades;

elaboração do plano de testes para a aplicação BackOffice; integração da equipa iWaterWeb na plataforma, para o

desenvolvimento de uma aplicação Web; reformulação do serviço de dados; implementação da interpretação de

mensagens protocolares da ISA; reformulada integração com iCenter para padrão Plug-In; elaboração de protótipo

para comparação de desempenho entre modelos de dados; elaboração de protótipo para verificar o uso de Bing

Maps para mostrar conteúdo georreferenciado; elaborados testes unitários para os desenvolvimentos já

implementados; refactoring do acesso à camada de negócios em pedidos das aplicações Web. Melhorado o tempos

de resposta do servidor; planeado alterações necessárias à implementação dos presenters das aplicações Web de

modo a melhorar o tempo de resposta do servidor de aplicações Web.

O iTelemetry é uma plataforma de desenvolvimento na ISA, conhecida internamente como uma plataforma

estruturante.

6.1 OVERV IEW DA ACTIVIDADE

6.2 ÂMBITO DO PROJECTO

O iTelemetry é um projecto ambicioso

diferentes negócios da ISA. A sua informação e modelo foram desenvolvidos com um nível de abstracção bastante

elevado permitindo o uso do iTelemetry para qualquer aplicação que utilize os recursos

desenvolvidos pela ISA. Para além da centralização dos conceitos e informação usada pelas várias aplicações da

ISA, o iTelemetry tem de ser bastante modular, permitindo que as várias componentes utilizadas por uma

aplicação possam ser substituídas de acordo com

O iTelemetry é um sistema que corre em ambiente Windows,

Conforme mostrado na Figura 37

telemetria para os clientes, bem como para uso interno.

Unidade - Equipamento desenvolvido pela ISA

junto dos seus pontos de monitorização. As unidades recolhem e enviam dados e/ou alarmes de acordo com o que

monitorizam. Ex: iLogger, iWater, iBottleRack

Tag - Representa um dos canais

uma unidade são enviados através de cada uma das suas

recolhidos de uma determinada grandeza. Ex:

6.3 CONCEITOS DO PROJECTO


O iTelemetry é um projecto ambicioso na medida em que este pretende centralizar a gestão e informação dos


elevado permitindo o uso do iTelemetry para qualquer aplicação que utilize os recursos

Para além da centralização dos conceitos e informação usada pelas várias aplicações da


aplicação possam ser substituídas de acordo com o seu contexto e necessidades.

que corre em ambiente Windows, desenvolvido em .NET com a linguagem C#.

37, o iTelemetry ambiciona servir de base para o desenvolvimento de apli

telemetria para os clientes, bem como para uso interno.

Figura 37 Conceito iTelemetry

desenvolvido pela ISA para monitorização remota. Uma unidade é instalada no terreno,

o dos seus pontos de monitorização. As unidades recolhem e enviam dados e/ou alarmes de acordo com o que

Ex: iLogger, iWater, iBottleRack.

Figura 38 Exemplo de Unidades

dos canais de comunicação de uma unidade. Os dados das várias monitorizações feitas por

uma unidade são enviados através de cada uma das suas Tags. Os dados transmitidos pelas

recolhidos de uma determinada grandeza. Ex: Média, Valores Instantâneos.

ONCEITOS DO PROJECTO


57

centralizar a gestão e informação dos


elevado permitindo o uso do iTelemetry para qualquer aplicação que utilize os recursos e equipamentos

Para além da centralização dos conceitos e informação usada pelas várias aplicações da


desenvolvido em .NET com a linguagem C#.

, o iTelemetry ambiciona servir de base para o desenvolvimento de aplicações de

para monitorização remota. Uma unidade é instalada no terreno,

o dos seus pontos de monitorização. As unidades recolhem e enviam dados e/ou alarmes de acordo com o que

Os dados das várias monitorizações feitas por

s. Os dados transmitidos pelas Tags são valores


58

Descritor de Tag - Significado atribuído a um dado vindo de uma

grandeza que precisam de ser contextualizados.

Sinal GSM, Bateria.

Figura

Elemento - Objecto físico monitorizado pelos canais de um ou mais equipamentos.

caracterizados pelas propriedades (Descritores de Tag) que monitorizam.

Garrafas.

Figura

Local - Localização geográfica que identifica o conjunto de elementos monitorizados

equipamentos. Ex: Hospital de Coimbra, Câmara Coimbra, Posto de abastecimento de Coimbra.

DDeevveellooppeerr

Figura 39 Dados transmitidos através de Tags

Significado atribuído a um dado vindo de uma Tag. Os dados de Tag

grandeza que precisam de ser contextualizados. Ex: Pressão de um tanque, Nível de Combustí

Figura 40 Descritores de Tag atribuídos a dados transmitidos

Objecto físico monitorizado pelos canais de um ou mais equipamentos.

des (Descritores de Tag) que monitorizam. Ex: Tanque, Sala de estar, Armário de

Figura 41 Elemento Tanque com alguns descritores de Tag

Localização geográfica que identifica o conjunto de elementos monitorizados

de Coimbra, Câmara Coimbra, Posto de abastecimento de Coimbra.

Tags são valores de uma certa

ombustível, Caudal de Água,

Objecto físico monitorizado pelos canais de um ou mais equipamentos. Os elementos são

Ex: Tanque, Sala de estar, Armário de

Localização geográfica que identifica o conjunto de elementos monitorizados por um ou mais

de Coimbra, Câmara Coimbra, Posto de abastecimento de Coimbra.

Cliente - Pessoa ou entidade à qual são prestados os serviços de telemet

6.3.1 I CENTER

O iCenter é outra plataforma estruturante dentro da ISA, responsável pela gestão das comunicações entre os

servidores da ISA e as unidades, disponibilizando

O iCenter disponibiliza os dados recebidos das unidades,

mensagens transmitidas pelas unidades.

plataforma é integrada no iTelemetry. A informação do iTelemetry sobre comunicações, dados e redes de

comunicação é estabelecida em concordância com um iCenter.


Figura 42 Um local com elementos sob monitorização

Pessoa ou entidade à qual são prestados os serviços de telemetria.

Figura 43 Possíveis clientes de Telemetria

orma estruturante dentro da ISA, responsável pela gestão das comunicações entre os

, disponibilizando-os para outras aplicações como o iTelemetry.

disponibiliza os dados recebidos das unidades, para além de notifica serviços quando

transmitidas pelas unidades. O iTelemetry tem uma relação muito próxima com o iCenter pois esta

integrada no iTelemetry. A informação do iTelemetry sobre comunicações, dados e redes de

comunicação é estabelecida em concordância com um iCenter.


59

orma estruturante dentro da ISA, responsável pela gestão das comunicações entre os

plicações como o iTelemetry.

notifica serviços quando são recebidas

O iTelemetry tem uma relação muito próxima com o iCenter pois esta

integrada no iTelemetry. A informação do iTelemetry sobre comunicações, dados e redes de


60

Enquanto o iCenter trata de comun

disponibilizada pelo iCenter dando

O iCenter gere as comunicações das unidades e recebe os dados transmitidos. Estes dados monitorizam elementos

em locais georreferenciados que pertencem a clientes, e que podem ser consultados por alguns utilizadores.

Atribuindo aos dados recebidos a contextualização

iTelemetry permite o uso desta informação para aplicações finais

em conhecimento.

A arquitectura iTelemetry é apresentada em dois formatos. É mostrado quais os componentes físicos que

constituem a solução (arquitectura física) e os componentes de so

6.4.1 ARQUITECTURA F

A arquitectura física do iTelemetry compreende a interacção entre vários componentes

funciona sobre a rede móvel e sobre uma rede em domínio Windows.

6.4 ARQUITECTURA I TELEMETRY

DDeevveellooppeerr

Figura 44 Comunicação entre Unidades e iCenter

o iCenter trata de comunicações entre unidades e a ISA, o iTelemetry contextualiza

disponibilizada pelo iCenter dando-lhe significado.


iados que pertencem a clientes, e que podem ser consultados por alguns utilizadores.

Atribuindo aos dados recebidos a contextualização em propriedades de elementos que se encontra num local o

o uso desta informação para aplicações finais. O iTelemetry permite a transformação de dados


constituem a solução (arquitectura física) e os componentes de software envolvidos (arquitectura lógica).

F ÍSICA

A arquitectura física do iTelemetry compreende a interacção entre vários componentes

funciona sobre a rede móvel e sobre uma rede em domínio Windows.

ELEMETRY

icações entre unidades e a ISA, o iTelemetry contextualiza a informação


iados que pertencem a clientes, e que podem ser consultados por alguns utilizadores.

que se encontra num local o

O iTelemetry permite a transformação de dados


ftware envolvidos (arquitectura lógica).

A arquitectura física do iTelemetry compreende a interacção entre vários componentes físicos distintos. O sistema

A Figura 45 mostra os vários componentes físicos que compõem o iTelemetry:

Componentes físicos são monitorizados por unidades (iLoggers e SMAlerts) da ISA (tanques no exemplo

anterior), que transmitem os seus dados para os servidores iCenter da ISA.

persistem dados nas suas bases de dados, notificando serviços do iTelemetry que tratam os dados das suas

unidades, persistindo informação relevante nos dados i

O servidor de aplicações Web do iTelemetry disponibiliza aos clientes os dados, informação e conhecimento de

telemetria através aplicações à medid

6.4.2 ARQUITECTURA L

Em termos lógicos, conforme especificado na

• Camada de serviços e apresentação

• Camada de negócio

• Camada de acesso a dados.


Figura 45 Arquitectura Física

mostra os vários componentes físicos que compõem o iTelemetry:

omponentes físicos são monitorizados por unidades (iLoggers e SMAlerts) da ISA (tanques no exemplo

transmitem os seus dados para os servidores iCenter da ISA. Internamente, os servidores iCenter


unidades, persistindo informação relevante nos dados iTelemetry.


telemetria através aplicações à medida.

LÓGICA

conforme especificado na Figura 46, o iTelemetry é uma plataforma com

Camada de serviços e apresentação

Camada de acesso a dados.


61

omponentes físicos são monitorizados por unidades (iLoggers e SMAlerts) da ISA (tanques no exemplo

Internamente, os servidores iCenter



elemetry é uma plataforma com 3 camadas:


62

Estas camadas seguem implementações e padrões de implementa

Esta fornece acesso aos dados do iTelemetry e os dados dos sistemas integrados pelo iTelemetry

superiores.

Actualmente, o iTelemetry apenas integra um outro sis

Esta camada define o interface para a gestão da persistência dos dados do que dizem respeito apenas ao

iTelemetry.

A camada de acesso a dados é

operações de persistência das diferentes partes do negócio. Ex: A DAL define um interface para persistir dados e,

nesse interface existe um DataMapper para a gestão da persistência

Data Access & Integration

ITelemetry DAL

DDeevveellooppeerr

Figura 46 Arquitectura Lógica iTelemetry

Estas camadas seguem implementações e padrões de implementação específicos, que são explicadas de seguida.

fornece acesso aos dados do iTelemetry e os dados dos sistemas integrados pelo iTelemetry

Actualmente, o iTelemetry apenas integra um outro sistema em si: iCenter.

Figura 47 Camada de Acesso a Dados do iTelemetry


A camada de acesso a dados é constituída por vários DataMappers, que são essencialmente interfaces para


nesse interface existe um DataMapper para a gestão da persistência de elementos, o IElementDataMapper.

& Integration Layer

ção específicos, que são explicadas de seguida.

fornece acesso aos dados do iTelemetry e os dados dos sistemas integrados pelo iTelemetry para as camadas


constituída por vários DataMappers, que são essencialmente interfaces para


de elementos, o IElementDataMapper.

O iCenterDAL é um interface para efectuar operações sobre um iCenter.

O iCenter oferece vários interfaces de acesso, e por esta razão, o meio de

transparente para o resto do sistema. Assim, o iCenterDAL é outro interface que faz parte da camada de acesso a

dados e integação do iTelemetry.

A camada Business Layer é a típica camada onde reside

A camada está organizada através de Controllers, que agregam em si operações respeitantes às várias partes do

negócio, e utilizam a interface iTelemetry DAL e iCenterDAL para concluírem as suas funções

49. Os Controllers estão responsáveis por garantir a integridade dos dados e das operações, trabalhando sempre

com transacções distribuídas (devido à existência de várias bases de dados em uso) e retornando valores bem

definidos para as camadas superiores que solicitam os serviços desta camada.

ICenterDAL

Business Layer


Figura 48 Interface do iTelemetryDAL

O iCenterDAL é um interface para efectuar operações sobre um iCenter.

O iCenter oferece vários interfaces de acesso, e por esta razão, o meio de comunicação com o iCenter tem de ser


dados e integação do iTelemetry.

A camada Business Layer é a típica camada onde residem as regras do negócio.


negócio, e utilizam a interface iTelemetry DAL e iCenterDAL para concluírem as suas funções

ontrollers estão responsáveis por garantir a integridade dos dados e das operações, trabalhando sempre


uperiores que solicitam os serviços desta camada.


63

comunicação com o iCenter tem de ser



negócio, e utilizam a interface iTelemetry DAL e iCenterDAL para concluírem as suas funções, conforme a Figura

ontrollers estão responsáveis por garantir a integridade dos dados e das operações, trabalhando sempre



64

A camada de negócios contém essencialmente as seguintes partes:

• Controladores que não necessitam de autenticação

Estes controladores contêm as operações básicas pa

Fornecem funcionalidades que não interferem com os dados dos clientes, mas permitem a autenticação

um utilizador para o uso do sistema. As funcionalidades de logging e gestão de erros também

funcionar mesmo sem um utilizador autenticado.

• Controladores que necessitam de autenticação

Estes controladores contêm as operações de negócio que necessitam de ter um utilizador autenticado para

aceder às suas operações.

• Utilitários para auxiliar lógica do negócio

Os utilitários encontram

comum como o cálculo georreferenciado, exportações para Excel e periodicidades de comunicação das

unidades necessitam de ser utilizados para várias operações e, por isso fazem parte da camada de

negócios.

• Fachada da Camada de negócio

A fachada de acesso à camada de negócios é identificada no modelo através do

Este componente fornece acesso aos C

telemetria) e permite identificar um utilizador, bem como uma aplicação que opera sobre a camada de

negócio.

DDeevveellooppeerr

Figura 49 Componentes da Business Layer

A camada de negócios contém essencialmente as seguintes partes:

Controladores que não necessitam de autenticação – Roxo

contêm as operações básicas para correr o sistema iTelemetry.

Fornecem funcionalidades que não interferem com os dados dos clientes, mas permitem a autenticação

um utilizador para o uso do sistema. As funcionalidades de logging e gestão de erros também

funcionar mesmo sem um utilizador autenticado.

Controladores que necessitam de autenticação – Vermelho


aceder às suas operações.

a auxiliar lógica do negócio - Azul

Os utilitários encontram-se disponíveis para uso dos vários controladores das áreas de negócio. Lógica


de ser utilizados para várias operações e, por isso fazem parte da camada de

Camada de negócio - Verde

A fachada de acesso à camada de negócios é identificada no modelo através do

componente fornece acesso aos Controllers (e consequentemente às operações de negócio de


ra correr o sistema iTelemetry.

Fornecem funcionalidades que não interferem com os dados dos clientes, mas permitem a autenticação de

um utilizador para o uso do sistema. As funcionalidades de logging e gestão de erros também têm de


se disponíveis para uso dos vários controladores das áreas de negócio. Lógica


de ser utilizados para várias operações e, por isso fazem parte da camada de

A fachada de acesso à camada de negócios é identificada no modelo através do GlobalController.

ontrollers (e consequentemente às operações de negócio de


Deste modo, as aplicações que necessitam de fazer as operações sobre o conhecimento de te

trabalhem apenas a nível conceptual.

• Gestor de acesso a dados

No modelo anterior, é possível ver que a camada de negócios utiliza dados persistidos através do interface

iTelemetryDAL e do iCenterDAL.

A interface para os dados é gerida pela

da camada de negócio.

Este componente implementa o padrão Singleton de modo a que a camada de negócios utilize o mesmo

acesso a dados durante a execução das operações dos Controllers

DALs disponíveis sempre que é necessário

A camada de serviços do iTelemetry é uma camada própria para serviços que operam automaticamente sobre o

sistema.

Um serviço executa uma certa lógica, e essa lógica tem de estar devidamente contida numa camada própria. Esta

convenção existe para facilmente utilizar as funcionalidades de um serviço noutro contexto

demonstrado na Figura 50. Ex: Unit T

A camada de aplicações Web contém todas as aplicações finais para os clientes da ISA.

A camada implementa o padrão d

comum entre as aplicações. Com o modelo MVP, é possível utilizar lógica existente para diferentes situações,

bastando apenas criar um novo interface para o

Services Layer

Web Applications Layer


Deste modo, as aplicações que necessitam de fazer as operações sobre o conhecimento de te

trabalhem apenas a nível conceptual.

Gestor de acesso a dados - cinza


iTelemetryDAL e do iCenterDAL.

A interface para os dados é gerida pela componente DALLoader, que é utilizada pelos vários


durante a execução das operações dos Controllers, evitando

DALs disponíveis sempre que é necessário obter um ou persistir um dado.


lógica, e essa lógica tem de estar devidamente contida numa camada própria. Esta

convenção existe para facilmente utilizar as funcionalidades de um serviço noutro contexto

. Ex: Unit Testing; Execução da funcionalidade do serviço manualmente;

Figura 50 Desenho dos serviços iTelemetry


A camada implementa o padrão de desenho MVP (Figura 51), juntamente com uma camada de recursos Web

Com o modelo MVP, é possível utilizar lógica existente para diferentes situações,

bastando apenas criar um novo interface para o Presenter em questão.

Web Applications Layer


65

Deste modo, as aplicações que necessitam de fazer as operações sobre o conhecimento de telemetria


, que é utilizada pelos vários Controllers


, evitando carregar dinamicamente as


lógica, e essa lógica tem de estar devidamente contida numa camada própria. Esta

convenção existe para facilmente utilizar as funcionalidades de um serviço noutro contexto, conforme

cução da funcionalidade do serviço manualmente;


, juntamente com uma camada de recursos Web

Com o modelo MVP, é possível utilizar lógica existente para diferentes situações,


66

Figura

O modelo MVP permite, para além do aproveitamento da lógica de apresentação, a execução de

sobre a lógica de apresentação. Isto é possível devid

como Mock Object ou uma implementação num GUI.

Com uma camada comum Web, é possível manter controlos asp.NET que podem ser u

aplicações Web, bem a estrutura geral das aplicações e estilo.

Neste capítulo encontra-se a descrição de alguns dos trabalhos realizados no âmbito do projecto iTelemetry.

Todo o trabalho realizado no âmb

complementar o que foi feito com a informação de como o trabalho foi realizado.

Cada subcapítulo contém a síntese de um trabalho mais pertinente.

6.5 SÍNTESE DE T RABALHOS

DDeevveellooppeerr

Figura 51 Padrão de Desenho Model View Presenter (MVP)

O modelo MVP permite, para além do aproveitamento da lógica de apresentação, a execução de

Isto é possível devido ao Presenter manipular uma vista. Esta vista pode ser usada

como Mock Object ou uma implementação num GUI.

Figura 52 Modelo Aplicações Web iTelemetry

Com uma camada comum Web, é possível manter controlos asp.NET que podem ser u

aplicações Web, bem a estrutura geral das aplicações e estilo.

se a descrição de alguns dos trabalhos realizados no âmbito do projecto iTelemetry.

Todo o trabalho realizado no âmbito do iTelemetry foi especificado no capítulo 0, servindo este capítulo para

complementar o que foi feito com a informação de como o trabalho foi realizado.

Cada subcapítulo contém a síntese de um trabalho mais pertinente.

RABALHOS REALIZADOS

O modelo MVP permite, para além do aproveitamento da lógica de apresentação, a execução de Unit Testing

manipular uma vista. Esta vista pode ser usada

Com uma camada comum Web, é possível manter controlos asp.NET que podem ser utilizados nas várias

se a descrição de alguns dos trabalhos realizados no âmbito do projecto iTelemetry.

, servindo este capítulo para


67

6.5.1 PROTÓTIPO PARA AVALIAR VELOCIDADE DE LEITURA

Devido à necessidade de utilização de um tipo de objecto na aplicação iBottleRack, foi necessário estudar qual o

melhor modelo de dados para persistir as especializações de elementos.

O iTelemetry contempla elementos que são o alvo das monitorizações a nível conceptual, como um tanque ou um

armário de garrafas. Para a aplicação iBottleRack, surgiu a necessidade de criar pela primeira vez uma

especialização de elementos: um elemento iBottleRack. O uso da aplicação iBottleRack implica que sejam feitas

pesquisas com enorme frequência sobre os dados específicos deste tipo de elementos.

O objectivo foi estudar qual o melhor modelo de dados que permitisse:

• Guardar informação extra sobre uma entidade.

• Ter boa performance de pesquisa sobre a informação extra

Conceptualmente, para efeitos de protótipo, criou-se o seguinte problema: Temos 10 000 Pessoas e 50 Artigos.

Um dos artigos tem o nome “alvo”. Pretende-se saber que pessoa tem o artigo com nome “alvo”.

Conceptualmente, uma pessoa pode ter uma série de artigos. Artigos apenas têm um dono. Com estas restrições,

foi o modelo criado o modelo da Figura 53.

Figura 53 Modelo Conceptual do Problema

O primeiro modelo de dados (Figura 54) representa a relação através de duas tabelas, onde o idDono da tabela

artigos é chave estrangeira da tabela Pessoas:

Motivo do desenvolvimento

Objectivo

Modelo conceptual

Modelos de dados


68

Figura 54 Modelo de Dados 1

O modelo de dados 2 (Figura 55) representa a relação do modelo conceptual através do uso de uma tabela para

guardar a informação de cada Pessoa. Os artigos que essa pessoa poderá ter serão guardados sob o formato XML

no campo artigos. Neste modelo de dados, esse campo XML é untyped. Ou seja, são aceites qualquer tipo de

XML.


No modelo de dados 3 (Figura 56), representamos a relação da entidade Pessoa com a entidade Artigo através de

um campo XML, à semelhança do modelo 2. A diferença é que neste modelo, o campo XML é typed. Ou seja,

apenas serão aceites para esse campo operações sobre o XML que respeite o esquema com que este é construído.



69

O esquema XML que o campo artigos aceita é o seguinte:

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementformdefault="qualified"> <xsd:element name="ArrayOfArtigo"> <xsd:complextype> <xsd:complexcontent> <xsd:restriction base="xsd:anyType"> <xsd:sequence> <xsd:element name="Artigo" minoccurs="0" maxoccurs="unbounded"> <xsd:complextype> <xsd:complexcontent> <xsd:restriction base="xsd:anyType"> <xsd:sequence> <xsd:element name="Nome" type="xsd:string" /> </xsd:sequence> </xsd:restriction> </xsd:complexcontent> </xsd:complextype> </xsd:element> </xsd:sequence> </xsd:restriction> </xsd:complexcontent> </xsd:complextype> </xsd:element> </xsd:schema>

O plano de testes englobava a execução da pesquisa sobre cada um dos modelos de dados, com o uso de 2

tecnologias diferentes: ADO.NET e Entity Framework 3.5.

Os testes tinham de ser executados com dois contextos distintos: Query executada ao SqlServer com os dados em

cache, e executada com os dados sem estarem na cache. A execução dos testes com a ausência dos dados em cache

no SqlServer foi conseguida parando e iniciando o serviço conforme necessário.

Os melhores resultados foram conseguidos pelo ADO.NET, o que não era inesperado. A Entity Framework corre

por cima da ADO.NET. O modelo de dados que apresentou melhores resultados foi o modelo com 2 tabelas.

Como conclusão do protótipo, foi tomada a decisão de utilizar o modelo com 2 tabelas, com recurso à Entity

Framework.

O uso de XML seria óptimo, mas como a Entity Framework 3.5 não suporta XML, esta lacuna teve de ser

contornada com lógica adicional, o que causou resultados bastante baixos (9). Quando a Entity Framework

suportar XML, novos testes serão realizados a fins de procurar a melhor solução para esta funcionalidade vital do

iTelemetry.

Plano de Teste

Resultados

Conclusão

Aplicação no iTelemetry


70

De acordo com as conclusões retiradas do protótipo, a funcionalidade foi desenvolvida com recurso à Entity

Framework e 2 tabelas. Esta lógica e desempenho foram utilizados na aplicação iBottleRack num dos relatórios

que este disponibiliza.

A lógica do protótipo aqui foi adaptada para a pesquisa de Elementos iBottleRack (correspondente a pessoas no

protótipo) que sem encontram em alarme (correspondente ao artigo ‘alvo’ no protótipo) (Figura 57).

Figura 57 Aplicação final que tira partido do protótipo

6.5.2 PROTÓTIPO CONTEÚDO GEORREFERENCIADO COM BING MAPS

O iTelemetry tem funcionalidades de georeferenciação e apresentação de conteúdo dinâmico sobre mapas. No

âmbito do desenvolvimento de uma funcionalidade da aplicação iBottleRack: a apresentação visual dos elementos

iBottleRacks no mapa de uma zona de distribuição.

Para implementar esta funcionalidade foram consideradas algumas soluções. Uma das soluções em consideração

foi o uso do Bing Maps como alternativa à implementação da funcionalidade (10).

Os objectivos do protótipo eram implementar as seguintes funcionalidades:

• Carregar dinamicamente pontos de interesse personalizados.

• Aumentar e diminuir o tamanho dos ícones dos pontos de interesse conforme o zoom no mapa.

A contextualização do protótipo foi mostrar um mapa centrado em Coimbra, com o ponto de interesse as

instalações da ISA juntamente com uma descrição.

Introdução

Objectivo

A implementação do protótipo passou por duas fases distintas.

Foi iniciada uma efectuada uma implementação do protótipo em

O protótipo foi desenvolvido utilizando o controlo

interesse foi realizada em C# com recurso ao controlo opensource no processamento de um pedido http. A

funcionalidade de zoom foi implementada em

evento de zoom.

A Figura 58 mostra os conceitos de interesse do Bing Maps, partilhado pelo

seguida explicados.

Um mapa tem um centro definido por latitude e longitude. Um mapa tem várias camadas que vão conter

(no nosso caso PushPins que são pontos de interesse). As

latitude e longitude.

Implementação

Entidades que compõem o Bing Maps


A implementação do protótipo passou por duas fases distintas.

Foi iniciada uma efectuada uma implementação do protótipo em AJAX, e com recurso a um controlo opensource.

O protótipo foi desenvolvido utilizando o controlo opensource em conjunto com AJAX

com recurso ao controlo opensource no processamento de um pedido http. A

funcionalidade de zoom foi implementada em AJAX, sendo processada pelo browser cliente

mostra os conceitos de interesse do Bing Maps, partilhado pelo API AJAX

Figura 58 Modelo Domínio Bing Maps

Um mapa tem um centro definido por latitude e longitude. Um mapa tem várias camadas que vão conter

que são pontos de interesse). As Shapes são posicionadas geograficamente através da

Entidades que compõem o Bing Maps


71

, e com recurso a um controlo opensource.

AJAX. A criação dos pontos de

com recurso ao controlo opensource no processamento de um pedido http. A

, sendo processada pelo browser cliente quando é lançado um

AJAX e pelo asp.net que são de

Um mapa tem um centro definido por latitude e longitude. Um mapa tem várias camadas que vão conter Shapes

são posicionadas geograficamente através da


72

Map: Esta classe é o coração do Bing Maps. O mapa é configurável sobre navegação, tipos de vista, zoom e a

informação personalizada é acessível através dele.

LatLong : Esta classe representa uma coordenada geográfica no formato Decimal Degrees.

ShapeLayer: Esta classe representa uma camada que será atribuída a um mapa. Uma camada poder conter em si

várias Shapes. O seu objectivo é fornecer funcionalidades sobre um grupo de Shapes.

Shape: Esta classe representa um ponto de interesse. Este poderá ser PushPin, Polygon ou Polyline. As Shapes

podem ter um título, descrição entre outros atributos.

PushPin representa um pin sobre o mapa (ex: Estação de autocarros). Polygon representa um pin que descreve

uma área. Exemplo: pin descreve “Área de cobertura de serviço” e a área mostra um distrito. Um polyline

representa um pin sobre linhas. Exemplo: pin descreve “Estação coimbra” as linhas demonstram as estradas

servidas.

A implementação do zoom foi feita com javascript. O controlo opensource permite a especificação de uma rotina

em javascript quando são detectados alguns eventos.

Um dos eventos que permite a especificação de uma rotina é o evento OnClientEndZoom que é disparado no

fim de um zoom no controlo do mapa.

<ve:Map ID="Map1" runat="server"

OnClientEndZoom="mudaTamanhoIconesConformeZoom" />

A rotina resizePointsOfInterest tem um papel simples: percorrer o DOM em busca do mapa e requerer um resize

dos PushPins. Com acesso ao mapa, apenas é necessário percorrer as camadas existentes no mapa para

redimensionar as Shapes (neste caso PushPins) para o tamanho desejado.

O tamanho é calculado através de uma propriedade que um mapa possui: Zoom Level. Este valor varia entre 1

(visualização do mapa mundo) e 19 (visualização mais perto do solo terreste). Na prática, uma imagem que tenha

de se adaptar conforme o zoom terá as suas propriedades width e height adaptadas de acordo com este Zoom

Level.

O resizing das Shapes é feito com o método SetCustomIcon() que permite definir a imagem do ponto de interesse.

Para o efeito de zoom, basta definir correctamente o tamanho da imagem usada manipulando o widht e o height da

imagem usada no PushPin:

Implementação Zoom AJAX

Cálculo do Tamanho & Resizing das Images


73

thisShape.SetCustomIcon("<img width=" + tamanho + " heigth=" + tamanho + "

src=\'"+imgUrl+"\' />");

O controlo opensource usado para este protótipo encapsula a manipulação do AJAX API.

Com o objectivo de verificar a facilidade da recriação de pontos de interesse em locais específicos com informação

personalizada, foi simulado no evento de page load a recriação de um ponto de interesse juntamente com alguma

informação auxiliar.

O ponto de interesse escolhido foi em Coimbra, mais propriamente no estádio da Académica onde são actualmente

as instalações da ISA, com coordenadas em Decimal Degrees (40.25, -8.45).

A implementação baseou-se em duas partes distintas: criação e posicionamento do mapa; elaboração de um ponto

de interesse.

As classes que o controlo opensource disponibiliza são semelhantes à API AJAX, partilhando o nome das classes,

métodos, argumentos e estruturas.

Deste modo, a preparação do mapa necessita apenas de ser definido com algumas propriedades:

Map1.MapStyle = MapStyle.Road;

Map1.ZoomLevel = 10;

Map1.MapMode = MapMode.Mode2D;

Map1.Center = new LatLong(40.25,-8.45);

Com estas linhas de código, o mapa ficou centrado em Coimbra, nas instalações da ISA no estádio municipal com

visibilidade já aproximada, visualizando o mapa em 2D e com estilo Road.

Os pontos de interesse são criados nas layers sobre um mapa.

A elaboração de um ponto de interesse, segundo o modelo de dados do bing maps, necessita apenas de uma Shape

(neste caso PushPin) com coordenadas associado a uma shapelayer que pertence ao mapa.

Esta lógica está recriada no seguinte código:

ShapeLayer layer = new ShapeLayer();

Implementação Carregamento de Pontos de Interesse

Criação e Posicionamento do mapa

Elaboração de um ponto de interesse


74

Shape sedeISA = new Shape(ShapeType.Pushpin, new LatLongWithAltitude(40.203333, -8.4075)); sedeISA.Title = "<h2>ISA Headquarter</h2>"; sedeISA.Description = "<p>Actuais instalações da ISA</p><p>Situa-se perto do <a href=\"//www.dolcevita.pt\">Dolcevita</a>"; sedeISA.CustomIcon = "<img width=100 heigth=100 src='”+imgUrl+”' />"; //associação do ponto de interesse á camada layer.AddShape(sedeISA); //associação da camada ao mapa Map1.AddShapeLayer(layer);

O protótipo provou a facilidade do uso de bing maps como alternativa de implementação de conteúdo

georeferenciado. Este protótipo irá reduzir o esforço de implementação de funcionalidades georreferenciadas

usadas no projecto iTelemetry e no departamento de software na ISA.

A Figura 59 e Figura 60 mostram o protótipo a correr.

Figura 59 Ponto de interesse sem descrição

Figura 60 Ponto de interesse com descrição visível, visualizando parte do mapa de Portugal

Conclusão


75

6.5.3 DICIONÁRIO DE EXCEPÇÕES

O iTelemetry possui capacidades de logging que visam permitir o rastreio de actividade na plataforma.

Actividades que ocorrem no âmbito das aplicações Web ou no âmbito do serviço de dados (entre outros) geram

entradas no log da plataforma. Com o iTelemetry em produção durante alguns meses, e durante o desenvolvimento

de funcionalidades reparou-se que o logging do iTelemetry tinha algumas limitações que provocaram algumas

dificuldades:

• Dificuldade ao identificar a origem de problemas.

• Havia alguma dificuldade em compreender a origem dos problemas.

Por vezes, tornou-se complicado perceber o que provocava erros na aplicação e onde é que estes ocorriam. Estes

problemas de logging estavam intimamente relacionados com:

• Uso e lançamento de excepções não uniforme

• Descrição das excepções não uniforme

Deste modo, os objectivos para o dicionário de excepções foram basicamente arranjar uma solução para as

necessidades e dificuldades sentidas.

Como tal, criou-se um dicionário de excepções capaz de:

• Identificar em que ponto do iTelemetry ocorre um problema.

• Identificar o âmbito aplicacional da excepção lançada.

• Uniformizar as mensagens de log originadas pelas excepções.

• Permitir o tratamento diferenciado para excepções específicas

o Excepções de configuração do sistema

o Excepções de corrupção de dados

O modelo do dicionário de excepções está representado na Figura 61, definindo a hierarquia das excepções e onde

estas são lançadas na arquitectura lógica

Necessidades

Objectivos

Modelo do Dicionário


76

.

Figura 61

Todas as excepções derivam do tipo de excepção genérica do iTelemetry.

Estas excepções ocorrem na camada de acesso a dados.

A camada de acesso a dados é composta por vários interfaces conhecidos c

fachada à persistência das entidades do sistema.

DataMapper que originou o problema. As excepções são geradas com uma descrição própria

acompanhadas por uma descrição personalizável

ControllerException são excepções geradas pela camada de negócio do sistema.

A camada de negócio do sistema é composta por vários controladores

entidades do negócio. Eles utilizam funcionalidades cedidas pela DAL e podem usar outros controladores.

Dados que estes actuam no âmbito de uma aplicação

excepções deste tipo é:

• O método que origina a excepção

• A aplicação que solicitou a operação

• O utilizador que estava a usar o sistema (

• Excepção que causa o problema

• Descrição personalizada

DALException

ControllerException

DDeevveellooppeerr

61 Âmbito das excepções e Diagrama de Classes das Excepções

Todas as excepções derivam do tipo de excepção genérica do iTelemetry.

Estas excepções ocorrem na camada de acesso a dados.

A camada de acesso a dados é composta por vários interfaces conhecidos como DataMappers, que servem de

fachada à persistência das entidades do sistema. As excepções deste tipo são capazes de identificar o método e o

DataMapper que originou o problema. As excepções são geradas com uma descrição própria

por uma descrição personalizável.

ControllerException são excepções geradas pela camada de negócio do sistema.

A camada de negócio do sistema é composta por vários controladores que aglomeram em si lógica e regras de

o. Eles utilizam funcionalidades cedidas pela DAL e podem usar outros controladores.

no âmbito de uma aplicação com um utilizador autenticado, a

O método que origina a excepção

solicitou a operação

utilizador que estava a usar o sistema (quando aplicável).

Excepção que causa o problema

Descrição personalizada

ControllerException

excepções e Diagrama de Classes das Excepções

omo DataMappers, que servem de

As excepções deste tipo são capazes de identificar o método e o

DataMapper que originou o problema. As excepções são geradas com uma descrição própria e podem ser

que aglomeram em si lógica e regras de

o. Eles utilizam funcionalidades cedidas pela DAL e podem usar outros controladores.

com um utilizador autenticado, a informação captada pelas


77

Estas são as excepções que ocorrem pelas aplicações que utilizam a camada de negócios do sistema.

Este tipo de excepção não foi desenvolvido a fundo, pois não houve ainda a necessidade da tipificação ou

tratamento especial dos erros deste género.

As excepções de configuração de sistema têm um tratamento especial.

Estas excepções têm especial interesse pois podem comprometer o bom funcionamento da plataforma. Estas

excepções podem ocorrer em qualquer camada do sistema.

Uma StartUpException é originada quando o sistema está a arrancar.

Ou seja, quando uma das várias aplicações começa a utilizar a camada de negócios e esta inicializa todos os seus

controladores e Plug-ins de acesso a dados. Uma excepção deste tipo impede o sistema de funcionar. Todas as

aplicações tratam uma excepção deste género notificando o utilizador a razão pela qual a aplicação não pode ser

utilizada.

Este género de excepções é lançado quando o sistema detecta que existem incoerência entre os dados com que

trabalha. No entanto, esta falha não impede o sistema de funcionar.

Este género de excepções capta a informação corrupta e notifica via mail e através do log a inconsistência de

dados detectada pelo sistema no contexto da aplicação que usa o iTelemetry.

Após a implementação do dicionário de dados no iTelemetry, passou a ser possível identificar as origens dos

problemas que ocorriam. Para além disso, sempre que é necessário instalar a plataforma ou instalar aplicações

iTelemetry as aplicações são capazes de dar informação útil ao utilizador permitindo-o rapidamente corrigir o

problema e colocar a plataforma a funcionar.

Com este dicionário de dados passou a manutenção do sistema tornou-se mais simples, pois quando existem

problemas com a integridade dos dados do sistema, os administradores são notificados com informação necessária.

ApplicationException

SystemConfigException

StartUpException

CorrupDataException

Benefícios


78

6.5.4 PERIODICIDADES DE COMUNICAÇÃO

Aquando do desenvolvimento da aplicação iWaterWeb pela sua equipa de desenvolvimento, a equipa iTelemetry

teve de dotar a plataforma para que esta conseguisse compreender as periodicidades das unidades.

O iWaterWeb tinha de conseguir mostrar qual a periodicidade definida nas unidades iWater da aplicação.

O objectivo deste desenvolvimento foi de dotar o iTelemetry do conhecimento das periodicidades de comunicação

das unidades, independentemente do seu tipo (iWater, iLogger, iBottleRack, etc).

O sistema tinha de conseguir persistir e retribuir a periodicidade definida para qualquer unidade.

Para atingir os objectivos, foram estudados todos os esquemas de comunicação possíveis para as unidades da ISA.

Com o objectivo de permitir flexibilidade no cálculo e aplicação das periodicidades, foi desenhado o modelo

representado na Figura 62, capaz de representar as periodicidades que as unidades da ISA podiam assumir:

Figura 62 Diagrama de classes das Periodicidades

As unidades podem ser configuradas com vários esquemas de periodicidade diferentes, dependendo do seu fim.

A emissão de dados recolhidos é enviada segundo uma periodicidade e, podem ser definidas periodicidades

diferentes para outros fins que não sejam o envio de dados para os sistemas da ISA.

A criação de objectos desta classe foi feita com o uso de fábrica abstracta.

Necessidades da implementação

Objectivos

Implementação

Com a capacidade de persistir e retribuir periodicidades de uma unidade, o iTelemetry ganhou meios para permitir

a avaliação das comunicações das unidades e actualidade de dados que podem ser utilizados para muitos fins.

Uma das utilizações imediatas foi no iWaterWeb, que fo

rede de unidades de um cliente.

iTelemetry perceber se as suas unidades comunicam conforme esperado e se os dados da plataforma

actualizados ou em falta.

6.5.5 REFORMULAÇÃO DO

O iTelemetry guarda e processa dados oriundos das várias unidades instaladas

Os dados surgem no iTelemetry devido à integração que o iTelemetry

um serviço específico para esse fim: o Serviço iTelemetry DataService.

Este serviço actua de forma passiva, aguardando notificações enviadas por um iCenter que recebe as mensagens de

dados das unidades instaladas no

Figura

Usabilidade

Contextualização

Necessidades de Mudança


persistir e retribuir periodicidades de uma unidade, o iTelemetry ganhou meios para permitir


Uma das utilizações imediatas foi no iWaterWeb, que foi dotada de um módulo para monitorização do estado da

rede de unidades de um cliente. Este conhecimento também é utilizado no módulo de estados, que permite ao

iTelemetry perceber se as suas unidades comunicam conforme esperado e se os dados da plataforma

EFORMULAÇÃO DO SERVIÇO DE DADOS

O iTelemetry guarda e processa dados oriundos das várias unidades instaladas nos locais dos seus clientes.

Os dados surgem no iTelemetry devido à integração que o iTelemetry tem com pelo menos um iCenter através de

um serviço específico para esse fim: o Serviço iTelemetry DataService.


nos vários locais dos clientes, tal como representado na

Figura 63 Entrada de Informação das Unidades no iTelemetry

Necessidades de Mudança


79

persistir e retribuir periodicidades de uma unidade, o iTelemetry ganhou meios para permitir


i dotada de um módulo para monitorização do estado da

Este conhecimento também é utilizado no módulo de estados, que permite ao

iTelemetry perceber se as suas unidades comunicam conforme esperado e se os dados da plataforma estão

locais dos seus clientes.

tem com pelo menos um iCenter através de


s vários locais dos clientes, tal como representado na Figura 63.


80

O serviço de dados foi criado para provar um conceito, sendo desenvolvido como protótipo que consumia

passivamente dados transmitidos em formato XML através dos serviços de comunicação WCF que fazem parte da

plataforma iCenter.

Pela natureza do protótipo, questões de escalabilidade e modulação não foram tidos em consideração aquando da

sua criação. No entanto, este serviço começou a ser utilizado na sua implementação original de protótipo e novas

funcionalidades foram inseridas ao longo do tempo conforme surgiam as necessidades.

Com o tempo, o serviço acumulou o processamento de várias mensagens juntamente com alguma complexidade

de integração com o iCenter.

Após análise do serviço e após a avaliação no esforço de manutenção e novos desenvolvimentos chegou-se às

seguintes conclusões:

• Alterações ao serviço ocupavam muito tempo.

• Logs de actividade gerados pelo processamento da recepção de mensagens não eram uniformes.

• Baixa coesão.

• Alto acoplamento.

O problema em questão é que para um serviço conceptualmente simples existia uma complexidade enorme.

A implementação passou por planear melhor a arquitectura do serviço.

Essencialmente, a lógica utilizada para processar uma mensagem foi isolada numa camada própria assente na

camada de negócio do iTelemetry.

Deste modo, o processamento de mensagens pode ser tratado com um módulo, permitindo a sua reutilização e

facilitando a gestão dos testes unitários criados para este módulo.

Apenas duas aplicações utilizam a lógica do processamento de mensagens:

• Consola de testes ao processamento de mensagens

• Serviço de dados

Esta camada tem como objectivo conter as regras aplicadas à interpretação e recepção de mensagens.

As regras de negócio para o processamento de mensagens no iTelemetry são:

• A recepção de mensagens não contempladas pela plataforma resulta num log de recebimento de

mensagem desconhecida.

Implementação

Camada de negócio de Processamento de Mensagens


81

• Cada processamento de mensagem deve originar apenas um log da sua actividade.

• Cada mensagem tem um processamento próprio de acordo com a natureza do seu tipo de mensagem no

seu protocolo.

• O processamento de uma mensagem tenta actualizar a data da última comunicação da unidade.

• A incapacidade de actualização da data da última comunicação da unidade não impede o processamento

do conteúdo desta.

• Caso haja um erro no processamento de uma mensagem, o serviço escreve um log com a descrição do

erro e um resumo do processamento efectuado com sucesso antes do erro.

Esta actividade resulta de interacções entre o iTelemetry e o iCenter.

De acordo com as regras para o processamento das mensagens, foram criadas as seguintes entidades com as

seguintes responsabilidades:

• MessageProcessor

Actua sobre um iCenter

Actua com um MessageProcessCoordinator

Permite efectuar o processamento de uma mensagem

Permite efectuar o processamento de mensagens antigas

• MessageProcessCoordinator

Coordena o processamento genérico de qualquer mensagem

Implementação com padrão template.

• Receptor de Eventos

Recebe mensagens de um iCenter

Gere integração com iCenter

Actua com um MessageProcessor

• IProtocolMessage

Representa o interface de qualquer mensagem processável

• MessageFactory

Entidades envolvidas no processamento de mensagens


82

Implementação com padrão fábrica

Abstrai a mensagem que deve ser processada.

Criar IProtocolMessages para serem processadas.

Na Figura 64é possível identificar as entidades utilizadas no processamento genérico de uma mensagem.

Existe uma entidade externa no modelo chamada ISA Protocols, que representa uma biblioteca da ISA capaz de

interpretar as mensagens codificadas transmitidas pelas unidades. Esta biblioteca é utilizada pela fábrica de

mensagens abstracta para conseguir criar objectos que implementam o interface IProtocolMessage.

Figura 64 Modelo de Domínio Processamento de Mensagens

Conforme demonstrado na Figura 65, a classe MessageFactory devolve instâncias de classes que implementam o

interface IProtocolMessage.

Actualmente, está definida a existência do processamento de mensagens protocolares e estão previstas o

processamento de outros tipos de mensagem. Devido a esta razão, a fábrica devolve IProtocolMessage em vez de

retornar AProtocolMessage.

Interacções entre entidades

Padrão Processamento de Mensagens Protocolares

Figura

AProcotolMessage é uma classe abstracta que representa uma mensagem protocolar. Ela implementa o interface

IProtocolMessage para ser utilizada pela fábrica.

O método Process vem do interface IProtocolMessage e

Figura


Figura 65 Diagrama de classes das Mensagens Protocolares


IProtocolMessage para ser utilizada pela fábrica.

O método Process vem do interface IProtocolMessage e é um template para processamento de mensagens:

Figura 66 Template do Processamento de AProtocolMessage


83


é um template para processamento de mensagens:


84

Para a geração uniforme de logs de actividade, o método Process do interface IProtocolMessage recebe parâmetro

out de tipo OperationSummary criado para este propósito.

A classe que coordena o processamento de uma mensagem interage com a fábrica de mensagens da seguinte

forma, conforme especificado na

Figura 67

O coordenador de processamento de mensagens é uma implementação do padrão Template. Para o padrão ser

capaz de funcionar com qualquer mensagem, foi necessário

Deste modo, a fábrica retorna um objecto processável que representa uma mensagem desconhecida.

Após a reformulação do serviço, o iTelemetry ganhou as seguintes vantagens:

• Altera-se o registo de act

• O processamento de novas mensagens consiste apenas

o Criar uma especialização de AProtocolMessage

� Implementar métodos abstractos

OnAft

o Ajustar a fábrica para

• O processamento de cada mensagem protocolar está isolado.

• É possível utilizar a funcionalidade de processamento de mensagens fora do contexto do serviço.

A equipa tirou partido desta nova im

• Implementação do processamento de mensagens novas. O tempo utilizado e bugs introduzidos foram

muito reduzidos.

Padrão Coordenador do Processamento de Mensagens

Benefícios

DDeevveellooppeerr


erationSummary criado para este propósito.


na Figura 67.

67 Template do Coordenador de Processamento de Mensagens


capaz de funcionar com qualquer mensagem, foi necessário criar também uma implementação do padrão NULL.


Após a reformulação do serviço, o iTelemetry ganhou as seguintes vantagens:

se o registo de actividade do processamento de mensagens com facilidade.

O processamento de novas mensagens consiste apenas:

riar uma especialização de AProtocolMessage

Implementar métodos abstractos ProcessMessage, OnBeforeProcessing e

OnAfterProcessing do padrão template

a fábrica para a nova especialização de AProtocolMessage.

O processamento de cada mensagem protocolar está isolado.

É possível utilizar a funcionalidade de processamento de mensagens fora do contexto do serviço.

A equipa tirou partido desta nova implementação quando ocorreram as seguintes situações:

Implementação do processamento de mensagens novas. O tempo utilizado e bugs introduzidos foram

Padrão Coordenador do Processamento de Mensagens



Template do Coordenador de Processamento de Mensagens


criar também uma implementação do padrão NULL.


ividade do processamento de mensagens com facilidade.

ProcessMessage, OnBeforeProcessing e

É possível utilizar a funcionalidade de processamento de mensagens fora do contexto do serviço.

plementação quando ocorreram as seguintes situações:

Implementação do processamento de mensagens novas. O tempo utilizado e bugs introduzidos foram


85

• Melhorar as entradas de log do serviço de dados. O tempo necessário para adaptar todas as entradas

geradas foi muito reduzido.

• Analisar dados em falta no sistema. Foi reduzido o esforço da análise, bastando quase consultar as

entradas de log para perceber a origem de problemas.

6.5.6 GESTÃO DE ELEMENTOS

O desenvolvimento da gestão de elementos inserido no módulo de Locais da aplicação BackOffice apresentou dois

desafios interessantes:

• Criação de conteúdo dinâmico para detalhes de elementos

• Comunicação entre vários Presenters

A gestão de elementos implica gerir todos os tipos de elementos que a plataforma suporta.

Para isto, a aplicação Web BackOffice tem de manter o mesmo layout para todos os elementos, diferenciando

apenas o conteúdo de uma aba específica: detalhes de elementos, conforme especificado na Figura 68.

Figura 68 ScreenShot da visualização de detalhes dos elementos

Os elementos de tipo não genérico têm detalhes específicos ao seu tipo. Elementos de tipo genérico não podem ter

detalhes, sendo a aba de detalhes escondida.

Criação de conteúdo dinâmico para detalhes de elementos

Objectivo


86

Para atingir este objectivo foram tidas em conta algumas alternativas de implementação, das quais a decisão final

recaiu entre:

• Uso do controlo MultiView, com uma View para cada tipo de elemento da plataforma.

• Criação dinâmica dos detalhes do tipo de elemento

A solução encontrada para ultrapassar este problema evitando problemas de escalabilidade foi a criação de um

User Control específico para cada tipo de elemento.

Como a página conhece o tipo de elemento em uso, apenas é necessário criar dinamicamente o conteúdo do

elemento em questão. Com esta solução, o User Control que mostra os elementos de um local mantém a mesma

estrutura independentemente do numero de tipos de elementos na plataforma.

Para adicionar novos tipos de elementos, a alteração a efectuar é adicionar no evento de Page_Init um controlo do

tipo de elemento em questão. Caso este passo não seja feito, a Framework não consegue reconstruir detalhes de

elementos entre postbacks.

O segundo desafio colocado foi a necessidade de contornar o uso típico do modelo MVP ao realizar operações de

leitura de dados oriundos de uma página, através de outro Presenter.

Figura 69 Presenters distintos com necessidade de comunicação

O problema em questão era o seguinte: Para efeitos de criação de um novo Elemento de tipo BottleRack, o

Presenter da vista de Elementos do local tinha de conseguir aceder aos dados fornecidos pelo Presenter

Solução Adoptada

BotteRackDetailsPresenter & ElementPresenter


87

BottleRack. Este funcionamento não é comum no modelo MVP e, por esta razão foi necessário encontrar um

mecanismo que permitisse ao Presenter de elementos aceder a dados da vista de detalhes BottleRack através do

Presenter de detalhes BottleRack.

A solução encontrada, visto que as operações de actualização e criação de elementos residem no Presenter de

elementos, foi preparar o Presenter de Elementos para trabalhar com outros Presenters.

Ao instanciar um controlo de detalhes BottleRack no âmbito do controlo de elementos, é passado como argumento

o Presenter do controlo de elementos. O controlo de detalhes BottleRack ao ser instanciado injecta o Presenter de

detalhes BottleRack no Presenter de elementos para que este possa trabalhar com detalhes BottleRack.

Foi necessário também adaptar as operações de criação e edição com uma condição que verifica o tipo de

elemento a persistir fazendo uso do Presenter necessário (neste caso BottleRack).

6.5.7 MÓDULO DE ESTADOS

O iTelemetry tem como funcionalidade principal servir de base tecnologia para as soluções de telemetria da ISA e,

deste modo, tem de possuir capacidades de monitorização das comunicações dos equipamentos com que lida.

Deste modo, surgiu a necessidade de criar um módulo que permitisse verificar em qualquer altura se as unidades

do iTelemetry estavam a conseguir estabelecer comunicação com o sistema, bem como se transmitiam

correctamente dados para o sistema. As unidades comunicam de acordo com um esquema de comunicação de dois

tipos diferentes. Pode ser definido para uma unidade que esta comunica de X em X minutos. Pode ser definido

uma hora e minutos a enviar para envio de mensagens, juntamente com os dias da semana em que o envio ocorre.

O desenvolvimento do módulo de estados envolveu actividades desde o levantamento dos requisitos e

necessidades dos utilizadores da aplicação até à implementação da funcionalidade.

Conforme se pode verificar na Figura 70, a recepção dos dados das unidades vêm através de mensagens. As

mensagens podem chegar ao sistema correctamente (1). As mensagens podem ser transmitidas e não chegarem ao

iCenter (2). As mensagens podem não ser emitidas pelas unidades (3) por alguma razão. As mensagens são

recebidas, mas são mal formadas (4).


88

Os objectivos para o módulo de estados do iTelemetry eram permitir:

• Conhecer o estado das comunicações de todas as unidades na plataforma.

• Conhecer o estado da recepção de dados de todas as unidades na

• Visualizar de forma resumida o estado das comunicações dos clientes.

• Consultar dados recebidos numa

Os requisitos finais para o módulo foram criados após algum

sobre as funcionalidades do módulo bem como a prototipagem do GUI junto dos utilizadores alvo da aplicação.

O interface para este módulo foi definido através de um protótipo que passou por validação

várias entidades: equipa, Product Owner

Neste capítulo são mostrados os ecrãs prototipados, juntamente com a descrição da funcionalidade esperada.

Pesquisa de unidades no sistema:

Objectivos

Interface no Backoffice

Protótipos

DDeevveellooppeerr

Figura 70 Entrada de dados no iTelemetry

Os objectivos para o módulo de estados do iTelemetry eram permitir:

Conhecer o estado das comunicações de todas as unidades na plataforma.

Conhecer o estado da recepção de dados de todas as unidades na plataforma.

Visualizar de forma resumida o estado das comunicações dos clientes.

recebidos numa unidade.

Os requisitos finais para o módulo foram criados após algum brainstorm com o Product Owner

o módulo bem como a prototipagem do GUI junto dos utilizadores alvo da aplicação.

O interface para este módulo foi definido através de um protótipo que passou por validação

Product Owner e os vários utilizadores finais.


Pesquisa de unidades no sistema:

Interface no Backoffice

Product Owner, alguma discussão

o módulo bem como a prototipagem do GUI junto dos utilizadores alvo da aplicação.

O interface para este módulo foi definido através de um protótipo que passou por validação e contribuição de



89

Figura 71 Screenshot do protótipo de pesquisa de unidades pelo estado de comunicação

O ecrã na Figura 71 permite consultar que unidades estão sob determinadas condições e, para cada unidade

permite: consultar os seus detalhes; consultar os seus dados recebidos; consultar a integridade com o iCenter que

recebe mensagens da unidade.

Resumo do estado das unidades dos clientes

Figura 72 Screenshot do protótipo de resumo das comunicações

Neste ecrã da Figura 72, o utilizador tem um resumo do estado das comunicações e estado dos dados para cada

cliente de modo a rapidamente identificar situações onde as unidades não comunicam ou quando os dados

emitidos não estão a ser actualizados como esperado.


90

Neste ecrã, é possível clicar no resumo do cliente e passar para o ecrã de consulta com uma pesquisa personalizada

(já com o cliente escolhido, tipo de unidade, estado da comunicação e estado dos dados).

A implementação do módulo de estados foi realizada em duas sprints, não se encontrando realizadas todas as

funcionalidades esperadas do módulo. A primeira versão está descrita no capítulo da Versão Alpha e a segunda

versão encontra-se descrita no capítulo da Versão Beta.

Versão Alpha

Conforme definido e prioritizado pelo Product Owner o ecrã que permitia a consulta das unidades foi o primeiro a

ser desenvolvido.

Este desenvolvimento apenas foi possível depois de preparar a camada de negócio para avaliar o estado de uma

unidade em relação às suas comunicações e a actualidade dos seus dados.

Versão Beta

A versão Beta foi realizada após a release da versão Alpha ter ido para produção. De acordo com o Product

Owner, foram definidos os desenvolvimentos a realizar no módulo de Estados na versão Beta.

Adição de funcionalidades à pesquisa de unidades

A pesquisa foi alterada para permitir paginação, para permitir ordenação e para permitir a consulta dos dados de

unidades bem como a visualização de detalhes das unidades, tal como demonstrado na Figura 73.

Implementação


91

Figura 73 GUI com acesso a mais informações das unidades

Preenchimento automático de resumos de cliente

Durante a Sprint onde se desenvolveu a versão beta do módulo de estados, desenhei juntamente com o resto da

equipa um mecanismo de actualização assíncrona da página sem ser necessária a intervenção do utilizador.

A Figura 74mostra como é que o mecanismo funciona:

Figura 74 Interacção entre componentes de modo Assíncrono

Este mecanismo funciona pois o controlo de resumo de cliente, sabendo a que cliente se refere, contém uma rotina

em Javascript que substitui o seu innerHtml pelo html que o WebService constrói. Esta rotina é feita em jQuery no

evento $(document).ready() que é disparado quando o carregamento do DOM está completo.


92

No final, a página ficou com aspecto demonstrado na Figura 75, onde se mostra um cliente ainda em

carregamento:

Figura 75 Screenshot do resumo das comunicações dos clientes

Integração entre Funcionalidades

Parte dos objectivos do módulo eram permitir a fazer uma consulta às unidades do sistema clicando nas estatísticas

respeitantes a unidades de um cliente.

Esta integração foi conseguida através do uso de querystrings interpretadas no evento de Page_Load. O esforço de

integração foi apenas de aplicar filtros de pesquisa antes de efectuar a chamada ao método PerformSearch() do

Presenter. O método executava a consulta e modificava a vista de acordo com os resultados segundo os filtros

seleccionados na página de consulta.

A implementação dos cálculos dos estados das comunicações de uma unidade e da actualidade dos dados foi feita

no Sprint em que se elaborou a versão alpha do módulo.

O cálculo do estado das comunicações funciona, a nível conceptual, de modo bastante simples, dependendo da

hora actual relativamente às comunicações esperadas.

Implementação do cálculo de estados

Cálculo do estado de Comunicações

Caso a unidade tenha comunicado após a última comunicação esperada, esta encontra

representado na pela Figura 76

esperada e entre a última comunicação esperada, esta falhou mais que uma comunicação e é considerada em

Atraso. Este caso está representado

Se a unidade falhou mais que duas comunicações previstas ou seja, a data da última

anterior à penúltima comunicação prevista esta está em Falha

A implementação do cálculo foi simples, embora tenha existido a necess

Periodicidades de comunicação para permitir adquirir as previsões de comunicação.

Os cenários identificados na imagem tornaram

O cálculo do estado dos dados também é simples

frequência, e esses dados são transmitidos numa comunicação da unidade.

Deste modo, os dados recebidos na ISA são dados recolhidos antes da transmissão e da recepção dos

Assim, sabendo que a unidade transmite pelo menos um dado nas suas comunicações peri

data do dado mais recente transmitido pela unidade traduz o estado da actualidade dos dados transmitidos.

Cálculo do estado de Dados


o a unidade tenha comunicado após a última comunicação esperada, esta encontra

zona verde. Caso a unidade tenha comunicado entre a penúltima comunicação

a comunicação esperada, esta falhou mais que uma comunicação e é considerada em

Este caso está representado pela zona amarela na Figura 76.

Se a unidade falhou mais que duas comunicações previstas ou seja, a data da última

anterior à penúltima comunicação prevista esta está em Falha que é a zona a vermelho.

Figura 76 Estado da comunicação de uma unidade

A implementação do cálculo foi simples, embora tenha existido a necessidade de dotar o modelo conceptual de

Periodicidades de comunicação para permitir adquirir as previsões de comunicação.

Os cenários identificados na imagem tornaram-se nas condições para os testes unitários.

também é simples a nível conceptual. Uma unidade recolhe dados com uma certa

frequência, e esses dados são transmitidos numa comunicação da unidade.

Deste modo, os dados recebidos na ISA são dados recolhidos antes da transmissão e da recepção dos

, sabendo que a unidade transmite pelo menos um dado nas suas comunicações peri


Cálculo do estado de Dados


93

o a unidade tenha comunicado após a última comunicação esperada, esta encontra-se em estado Ok, como

Caso a unidade tenha comunicado entre a penúltima comunicação

a comunicação esperada, esta falhou mais que uma comunicação e é considerada em

Se a unidade falhou mais que duas comunicações previstas ou seja, a data da última comunicação da unidade é

que é a zona a vermelho.

idade de dotar o modelo conceptual de

se nas condições para os testes unitários.

Uma unidade recolhe dados com uma certa

Deste modo, os dados recebidos na ISA são dados recolhidos antes da transmissão e da recepção dos mesmos.

, sabendo que a unidade transmite pelo menos um dado nas suas comunicações periódicas, é inferido que a



94

Caso a data do dado mais recente da unidade esteja situado entre a última e a penúltima datas de comunicação

previstas, o dado é recente foi adquirido e registado

Figura 77. Caso a data do dado mais recente da unidade esteja entre a penúltima e a antepenúltima comunicação

esperadas pela unidade, o dado é considerado em atraso

considerados em falha se foram recolhidas antes da antepenúltima comunicação esperada pela unidade.

A implementação do cálculo também foi simples, sendo apenas necessário fazer uso do cálculo

comunicação previstas de uma unidade

dados.

À semelhança do cálculo anterior, os testes unitários foram extraídos do modelo

condições identificadas, o sistema também tinha de compreender

recebidos.

O módulo desenvolvido tem-se revelado bastante útil pois os utilizadores podem aceder a funcionalidades e

conhecimento que normalmente requeriam algum tempo

Deste modo, a equipa de software deixou de ser interrompida para esclarecer e verificar problemas de integração e

falhas de comunicação.

6.5.8 PLUG-IN I CENTER

A arquitectura da solução iTelemetry foi pensada e concebi

padrão Plug-in foi implementado das camadas de acesso a dados.

Sentiu-se a necessidade de criar uma DAL para o iCenter que utilizasse como meio de comunicação uma class

library, ao invés do uso de mecanismos WCF para integração

Utilidade

DDeevveellooppeerr

Figura 77 Estados dos dados de uma unidade


previstas, o dado é recente foi adquirido e registado na última transmissão de dados, situando

Caso a data do dado mais recente da unidade esteja entre a penúltima e a antepenúltima comunicação

, o dado é considerado em atraso situando-se na zona amarela


A implementação do cálculo também foi simples, sendo apenas necessário fazer uso do cálculo

unidade de acordo com a sua periodicidade para tirar conclusões sobre o estado dos

À semelhança do cálculo anterior, os testes unitários foram extraídos do modelo na Figura

sistema também tinha de compreender situações como a ausência de

se revelado bastante útil pois os utilizadores podem aceder a funcionalidades e

conhecimento que normalmente requeriam algum tempo e colaboração com as equipas de software.


ENTERDLL

a da solução iTelemetry foi pensada e concebida para ser o mais modular possível e, por esta razão, o

in foi implementado das camadas de acesso a dados.

se a necessidade de criar uma DAL para o iCenter que utilizasse como meio de comunicação uma class

canismos WCF para integração com o iCenter.


na última transmissão de dados, situando-se na zona verde da

Caso a data do dado mais recente da unidade esteja entre a penúltima e a antepenúltima comunicação

se na zona amarela da Figura 77. Os dados são


A implementação do cálculo também foi simples, sendo apenas necessário fazer uso do cálculo das datas de

para tirar conclusões sobre o estado dos

Figura 77. Juntamente com as

situações como a ausência de Tags e dados

se revelado bastante útil pois os utilizadores podem aceder a funcionalidades e

e colaboração com as equipas de software.


da para ser o mais modular possível e, por esta razão, o

se a necessidade de criar uma DAL para o iCenter que utilizasse como meio de comunicação uma class


95

A implementação desta funcionalidade levou a alterações ao modelo de dados, bem como às configurações das

aplicações.

A mudança das configurações das aplicações sentiu-se pela seguinte razão: existiam mais entradas nos ficheiros de

configuração do que o necessário, tornando o ficheiro de configuração mais confuso do que o necessário.

A indicação da assembly a utilizar como acesso ao iCenter devia de ser o suficiente para o sistema conseguir saber

que mecanismo de comunicação é usado para comunicar com o iCenter. Foi neste sentido que a alteração foi feita,

de modo a que a configuração seja feita de uma das seguintes maneiras:

<add key="DAL.iCenter.Assembly" value="ISA.iTelemetry.DAL.iCenter.iCenterWCF" />

<add key="DAL.iCenter.Assembly" value="ISA.iTelemetry.DAL.iCenter.iCenterDLL" />

O modelo de dados teve de ser actualizado para suportar esta funcionalidade. Antes da implementação, o modelo

de dados apenas disponibilizava uma configuração em formato string para um iCenter.

Para que pudessem existir por iCenter várias configurações de acesso, algumas das possibilidades tomadas em

conta junto da equipa foram:

• Usar uma string para várias configurações, através de um parser.

• Usar XML para representar as várias configurações

Foi decidido utilizar XML para definir as configurações de acesso ao iCenter, pela facilidade de leitura, gestão de

dados e pela possibilidade de utilizar o modelo de dados para não aceitar configurações incorrectas.

Definido o modelo de dados para utilizar um campo XML tipificado, é possível impor a estrutura que define as

conexões que são utilizadas para aceder a iCenters: O esquema permite que um iCenter tenha apenas uma conexão

de cada tipo, sendo suportadas conexões por WCF e conexões por DLL conforme especificado de seguida:

Mudança na configuração

Mudança no modelo de dados


96

<?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="iCenterConnections"> <xs:complexType> <xs:sequence> <xs:element name="WCF" maxOccurs="1"> <xs:complexType> <xs:sequence> <xs:element name="Url" type="xs:string" /> <xs:element name="Binding" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="DLL" maxOccurs="1"> <xs:complexType> <xs:sequence> <xs:element name="ConnectionString" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element>

</xs:schema>

O sistema teve de ser alterado para suportar apenas o nome da assembly da DAL iCenter como indicação do

conteúdo a carregar.

Deste modo, cabe ao sistema interpretar a assembly definida nas configurações, carregando-a através do seu

interface, expondo o interface de acesso ao iCenter independentemente do mecanismo de comunicação com a

seguinte rotina:

Assembly iCenterAsm = Assembly.Load(m_DALiCenterAssembly); m_IDataMapperFactory = (IDataMapperFactory)dalAsm.CreateInstance(m_DALDMFactory); //Search iCenter Assembly for IiCenterDataMapperFactory. foreach (Type thisType in iCenterAsm.GetTypes()) if (thisType.GetInterface(typeof(IiCenterDataMapperFactory).FullName) != null) { m_IiCenterDataMapperFactory = (IiCenterDataMapperFactory)iCenterAsm.CreateInstance(thisType.FullName); break; } if (m_IiCenterDataMapperFactory == null)

throw new StartUpException(StartUpException.Scenario.DALFailedToLoad, "No iCenter

Factory was found in " + m_DALiCenterAssembly);

Com estas alterações e tendo os acessos definidos para um iCenter alternar facilmente entre o mecanismo que mais

vantagens traz de acordo com o contexto das aplicações.

Exemplo:

Implementação

Usabilidade


97

A máquina PFEIX tem um iCenter a correr, e o iTelemetry tem persistido os seguintes acessos a este iCenter:

<iCenterConnections xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <WCF> <Url>net.tcp://avalanche:8888/iCenterService</Url> <Binding>iCenterServiceTCP</Binding> </WCF> <DLL> <ConnectionString>Data Source=AVALANCHE;Initial Catalog=iCenter3;Persist Security Info=True;User ID=icenter;Password=icenter</ConnectionString> </DLL>

</iCenterConnections>

De acordo com as necessidades da aplicação, basta especificar a assembly a utilizar entre as duas entradas de

configuração da aplicação final para escolher o acesso ao iCenter:

<add key="DAL.iCenter.Assembly" value="ISA.iTelemetry.DAL.iCenter.iCenterWCF" />

<add key="DAL.iCenter.Assembly" value="ISA.iTelemetry.DAL.iCenter.iCenterDLL" />

6.5.9 ELABORAÇÃO DO PLANO DE TESTES AO BACKOFFICE

Na altura da primeira release da aplicação Web Backoffice, foi necessário elaborar um documento chamado

internamente por Plano de Testes.

A existência deste documento está prevista dentro da ISA pelo sistema de qualidade dentro do ciclo de vida da

concepção e desenvolvimento. Este indica que na fase final da elaboração de um produto ou solução tecnológica

tem de ser executado o plano de testes para o produto ou solução tecnológica ser entregue aos clientes finais de

modo a garantir a qualidade do serviço prestado.

Plano de Testes é o nome atribuído internamente ao artefacto que contém todos os testes que têm de ser

executados para uma aplicação com interface gráfico.

Este artefacto é utilizado para fins de garantir qualidade do serviço e para auxiliar a integração e evolução do

produto ou solução.

Para elaborar os testes para a aplicação BackOffice, foi utilizada a metodologia sugerida no livro Introduction To

Software Testing para testar aplicações Web.

Necessidade

Plano de Testes

Metodologia Utilizada


98

Foram moduladas interacções com cada funcionalidade das páginas originando grafos onde foram aplicados o

critério de cobertura considerado adequado, na maioria prime-path.

O exemplo do modelo foi extraído do módulo de utilizadores. O intuito deste teste é verificar que na visualização

dos dados do utilizador, as operações sobre o utilizador seleccionado se comportam como esperado.

Figura 78 Interacções a testar no módulo de utilizadores

Com base nas interacções assinaladas na Figura 78 a aplicação deve alternar entre 3 estados de visualização de

acordo com o estado do utilizador sob visualização. Da interacção esperada, extraiu-se o grafo apresentado na

Figura 79, juntamente com as condições que devem ser verificadas em cada estado de visualização.

Figura 79 Grafo dos estados de visualização

Ao usar a aplicação, um utilizador seleccionado por encontrar-se em qualquer um dos estados apresentados.

Qualquer um dos estados pode ser considerado um nó inicial, e qualquer um dos estados pode ser considerado nó

final.

Exemplo Modelo Interacção


99

Deste modo, os testes necessários para comprovar as interacções juntamente com os estados de visualização são os

seguintes:

T1: A, C, B – Visualizar um utilizador activo, de seguida bloqueá-lo e por fim remove-lo.

T2: A, C, A – Visualizar um utilizador activo, de seguida bloqueá-lo e por fim desbloqueá-lo.

T3: C, A, B – Visualizar um utilizador bloqueado, de seguida bloqueá-lo e por fim remove-lo.

T4: C, A, C – Visualizar um utilizador bloqueado, de seguida desbloqueá-lo e por fim bloqueá-lo.

Apesar de a elaboração dos testes ter consumido bastante tempo e ter originado uma grande quantidade de testes,

estes testes revelaram-se o mínimo para garantir que todas as funcionalidades da aplicação, bem com as

interacções com a aplicação funcionavam conforme esperado.

A elaboração do plano de testes permitiu à equipa resolver problemas antes da release aumentando a qualidade do

serviço prestado. Caso este plano de testes não tivesse sido feito metodicamente, a aplicação teria sido lançada

com problemas.

Utilidade


100

7 CONSIDERAÇÕES FINAIS

O trabalho realizado na ISA foi estimulante.

O conhecimento adquirido durante o mestrado foi aplicado em vários contextos, onde tive oportunidade de aplicar

a grande maioria dos conhecimentos que adquiri ao longo do meu percurso académico na vertente de

Desenvolvimento de Software, desde o Curso Tecnológico de Informática, à Licenciatura em Informática e

Sistema e ao Mestrado em Informática e Sistemas.

Apesar de o meu trabalho como Scrum Advisor ter ocupado uma pequena percentagem do meu estágio, gostei

imenso do trabalho realizado. A actividade de Scrum Advisor fez com que o meu conhecimento sobre Scrum e

sobre as metodologias de trabalho fosse alargado, pois absorvi muito conteúdo sobre Scrum fora do estágio através

da leitura de blogues, case Studies, livros e relatos sobre a adopção da metodologia. Com este trabalho, consegui

trazer para a ISA meios que permitem identificar problemas na adopção da metodologia e resolve-los. Com o meu

trabalho de Scrum Advisor, foi reconhecido que afinal existiam problemas na implementação actual de Scrum e

que esta tinha de ser melhorada em alguns aspectos.

O meu trabalho de cariz mais técnico trouxe muita experiência em técnicas e tecnologias que não eram a minha

especialidade. O uso de tecnologias como o Linq em .NET, Entity Framework, jQuery e todas as restantes

tecnologias com que trabalhei para servir as necessidades do iTelemetry fizeram com que eu explorasse novas

ferramentas e que atingisse níveis de performance de desenvolvimento muito melhores. Adquiri muita prática na

automatização de testes que me permitiu utilizar os conhecimentos das cadeiras de Design e Arquitectura de

Software bem como Testes e Qualidade de Software e elevar a qualidade dos desenvolvimentos.

Com a experiência adquirida tornei-me mais pragmático, que era uma qualidade que não tinha, pois o meu

trabalho era minucioso, perfeccionista e explorando muito antes de dar trabalho como concluído. Agora, sou capaz

de apresentar trabalho com elevada qualidade em muito menos tempo.

O trabalho de cariz mais técnico ocupou a maior parte do estágio e a experiência de colaborar na concepção de um

produto que é utilizado a nível global foi muito gratificante.

Pessoalmente, gostei bastante trabalhar na área de tecnologia da ISA pois tive oportunidade de trabalhar com

várias equipas que criam a tecnologia usada e trabalham em conjunto, desde a concepção do hardware ao

desenvolvimento de sistemas embutidos, criação de firmware e software.

De futuro, ambiciono aprofundar mais o conhecimento sobre Scrum e tornar-me Scrum Master, utilizando e

partilhando todo o meu conhecimento e experiência.

A nível tecnológico, espero alargar mais a minha experiencia a nível de arquitectura de Software, trabalho e

estudando soluções open-source bem como adquirir conhecimento e prática no desenvolvimento de aplicações


101

para dispositivos móveis com o Android como base tecnológica e continuar a colaborar com ferramentas

opensource.


102

8 REFERÊNCIAS

1. Wikipedia. Scrum (development). Scrum (development) - Wikipedia, the free encyclopedia.

[Online] http://en.wikipedia.org/wiki/Scrum_(development).

2. Schwaber, Ken. Agile Project Management with Scrum. s.l. : Microsoft Professional.

3. Wikipedia. Agile Software Development. [Online]

http://en.wikipedia.org/wiki/Agile_software_development.

4. Pereira, João Paulo. Comparativo de Conformidade Com as Regras. 2010.

5. —. Processo Avaliação Scrum - Avaliação das Regras Scrum.

6. —. Processo Avaliação Scrum - Avaliação Práticas Scrum. 2010.

7. Rally Software Development Corporation and Ken Schwaber. A CIO’s Playbook for

Adopting the Scrum Method of Achieving Software Agility. 2005.

8. Cohn, Mike. Metrics You Can Bet on. 2006.

9. Pereira, João Paulo. Re-Avaliação da Conformidade das Regras Scrum. 2010.

10. —. Proposta ao Processo Scrum - Proposta de Melhorias Faseadas. 2010.

11. —. Processo de Melhoria Contínua. 2010.

12. Agile Collab. Interview with Ken Schwaber, Scrum, Scrum and India, Scrum and

Outsourcing:. [Online] http://www.agilecollab.com/interview-with-ken-schwaber.

13. Mountain Goat Software. Introduction to Scrum - An Agile Process. [Online]

http://www.mountaingoatsoftware.com/topics/scrum.

14. Scrum Alliance. Scrum Alliance - Scrum Framework. [Online]

http://www.scrumalliance.org/pages/scrum_framework.

15. Baley, Kyle. Mindless vs. Mindful Meetings, or “How to think before you meet”. The

Coding Hillbilly - CodeBetter.Com - Stuff you need to Code Better! [Online]


103

http://codebetter.com/blogs/kyle.baley/archive/2009/05/08/mindless-vs-mindful-meetings-or-

how-to-think-before-you-meet.aspx.

16. Miller, Jeremy D. Retrospectives. CodeBetter - Stuff you need to know to code better!

[Online] http://codebetter.com/blogs/jeremy.miller/archive/2007/05/03/retrospectives.aspx.

17. Reffries, Jon. Beyond Agile — Inspect and Adapt? How? | xProgramming.com. [Online]

http://xprogramming.com/xpmag/beyond-agile-inspect-and-adapt-how/.

18. rdymond. A SCRUM PROJECT THAT FAILED. Innovel. [Online] 16 de May de 2008.

http://www.innovel.net/?p=62.

19. Krishnamurthy, Venkatesh. Agile Retrospective meetings for new scrum teams. Agile

Blog. [Online] http://agileworld.blogspot.com/2007/02/agile-retrospective-meetings-for-

new.html.

20. Joseph Pelrine & Jiri Lundack. Why Scrum Projects Fail. Scrum Alliance. [Online] 2007.

http://www.scrumalliance.org/resources/268.

21. Peter Beck & Andreas Schliep. Scrum Alliance - The Day After The Retrospective.

Scrum Alliance. [Online] 2008. http://www.scrumalliance.org/resources/437.

22. lacey, Mitch. Scrum Alliance - Done List Creation Exercise. Scrum Alliance. [Online]

2007. http://www.scrumalliance.org/resources/420.

23. Card, Danid N. The Challenge of Productivity Measurement. 2006.

24. Morris, Rob. Agile Estimation and Planning. 2006.

25. Clyne, Ken. Agility and Requirements. 2008.

26. Jffries, Ronald E. A Metric Leading To Agility. 2004.

27. E.Jeffries, Ronald. Running Tested Features Yet Again. 2008.

28. Rutherford, Kevin. running tested features are not enough. 2005.

29. Executive Brief. Metrics that Matter in Agile Projects. 2010.

Documents

AGRADECIMENTOSfiles.isec.pt/DOCUMENTOS/SERVICOS/BIBLIO/teses/Tese_Mest_Joa… · apresenta informação necessária a que qualquer membro de uma equipa de Scrum consiga avaliar a