Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
4
PALAVRAS -CHAVE
Scrum
Telemetry
iTelemetry
Design Patterns
Bing
ISA
K EYWORDS
Scrum
Telemetry
iTelemetry
Design Patterns
Bing
ISA
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.2 Daily Scrum Meeting ........................................................................................................ 43
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.2 Daily Scrum Meeting ........................................................................................................ 48
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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 55 Modelo de Dados 2 .................................................................................................................................. 68
Figura 56 Modelo de Dados 3 .................................................................................................................................. 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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
software da ISA. A actividade de Scrum Advisor surgiu para verificar a adopção da metodologia e auxiliar a
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
software da ISA. A actividade de Scrum Advisor surgiu para verificar a adopção da metodologia e auxiliar a
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy
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
O trabalho realizado sobre a medição da eficácia da adopção do Scrum e sugestão de melhorias foi focado na
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
O trabalho realizado sobre a medição da eficácia da adopção do Scrum e sugestão de melhorias foi focado na
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
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
O importante é que a pessoa que assume um papel faça o trabalho esperado do seu papel.
é 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
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 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
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 um dos papéis
O importante é que a pessoa que assume um papel faça o trabalho esperado do seu papel.
er 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
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
3.4.1 MÉTODO UTILIZADO
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
3.5.1 MÉTODO UTILIZADO
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
40
Figura 22 Exemplo de um Indicador de qualidade
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
4.1.2 DAILY SCRUM MEETING
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
Problemas Identificados
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
Problemas Identificados
Sugestões de Melhoria
Acções Tomadas
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
Problemas Identificados
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
Sugestões de Melhoria
Acções Tomadas
Resultados
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
48
4.2.2 DAILY SCRUM MEETING
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
Sugestões de Melhoria
Acções Tomadas
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
Problemas Identificados
Sugestões de Melhoria
Acções Tomadas
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoor
O iTelemetry é um projecto ambicioso na medida em que este pretende centralizar a gestão e informação dos
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
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 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
orr && iiTTeelleemmeettrryy DDeevveellooppeerr
57
centralizar a gestão e informação dos
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 e equipamentos
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
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy
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.
SSccrruumm AAddvviissoor
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.
orr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy
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.
O iCenter gere as comunicações das unidades e recebe os dados transmitidos. Estes dados monitorizam elementos
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
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 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
O iCenter gere as comunicações das unidades e recebe os dados transmitidos. Estes dados monitorizam elementos
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
A arquitectura iTelemetry é apresentada em dois formatos. É mostrado quais os componentes físicos que
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.
SSccrruumm AAddvviissoor
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
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 iTelemetry.
O servidor de aplicações Web do iTelemetry disponibiliza aos clientes os dados, informação e conhecimento de
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.
orr && iiTTeelleemmeettrryy DDeevveellooppeerr
61
omponentes físicos são monitorizados por unidades (iLoggers e SMAlerts) da ISA (tanques no exemplo
Internamente, os servidores iCenter
persistem dados nas suas bases de dados, notificando serviços do iTelemetry que tratam os dados das suas
O servidor de aplicações Web do iTelemetry disponibiliza aos clientes os dados, informação e conhecimento de
elemetry é uma plataforma com 3 camadas:
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy
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
Esta camada define o interface para a gestão da persistência dos dados do que dizem respeito apenas ao
A camada de acesso a dados é constituída por vários DataMappers, que são essencialmente interfaces para
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 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
Esta camada define o interface para a gestão da persistência dos dados do que dizem respeito apenas ao
constituída por vários DataMappers, que são essencialmente interfaces para
operações de persistência das diferentes partes do negócio. Ex: A DAL define um interface para persistir dados e,
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
SSccrruumm AAddvviissoor
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
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 residem as regras do negócio.
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
ontrollers 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
uperiores que solicitam os serviços desta camada.
orr && iiTTeelleemmeettrryy DDeevveellooppeerr
63
comunicação com o iCenter tem de ser
transparente para o resto do sistema. Assim, o iCenterDAL é outro interface que faz parte da camada de acesso a
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, conforme a Figura
ontrollers 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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy
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
Estes controladores contêm as operações de negócio que necessitam de ter um utilizador autenticado para
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
comum como o cálculo georreferenciado, exportações para Excel e periodicidades de comunicação das
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
telemetria) e permite identificar um utilizador, bem como uma aplicação que opera sobre a camada 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
Estes controladores contêm as operações de negócio que necessitam de ter um utilizador autenticado para
se disponíveis para uso dos vários controladores das áreas de negócio. Lógica
comum como o cálculo georreferenciado, exportações para Excel e periodicidades de comunicação das
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
telemetria) e permite identificar um utilizador, bem como uma aplicação que opera sobre a camada 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
SSccrruumm AAddvviissoor
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
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 componente DALLoader, que é utilizada pelos vários
Este componente implementa o padrão Singleton de modo a que a camada de negócios utilize o mesmo
durante a execução das operações dos Controllers, evitando
DALs disponíveis sempre que é necessário obter um ou persistir um dado.
A camada de serviços do iTelemetry é uma camada própria para serviços que operam automaticamente sobre o
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 de aplicações Web contém todas as aplicações finais para os clientes da ISA.
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
orr && iiTTeelleemmeettrryy DDeevveellooppeerr
65
Deste modo, as aplicações que necessitam de fazer as operações sobre o conhecimento de telemetria
No modelo anterior, é possível ver que a camada de negócios utiliza dados persistidos através do interface
, que é utilizada pelos vários Controllers
Este componente implementa o padrão Singleton de modo a que a camada de negócios utilize o mesmo
, evitando carregar dinamicamente as
A camada de serviços do iTelemetry é uma camada própria para serviços que operam automaticamente sobre o
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;
A camada de aplicações Web contém todas as aplicações finais para os clientes da ISA.
, juntamente com uma camada de recursos Web
Com o modelo MVP, é possível utilizar lógica existente para diferentes situações,
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
Figura 55 Modelo de Dados 2
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.
Figura 56 Modelo de Dados 3
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoor
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
orr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoor
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 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.
Este serviço actua de forma passiva, aguardando notificações enviadas por um iCenter que recebe as mensagens de
nos vários locais dos clientes, tal como representado na
Figura 63 Entrada de Informação das Unidades no iTelemetry
Necessidades de Mudança
orr && iiTTeelleemmeettrryy DDeevveellooppeerr
79
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.
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
Este serviço actua de forma passiva, aguardando notificações enviadas por um iCenter que recebe as mensagens de
s vários locais dos clientes, tal como representado na Figura 63.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoor
Figura 65 Diagrama de classes das Mensagens Protocolares
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 é um template para processamento de mensagens:
Figura 66 Template do Processamento de AProtocolMessage
orr && iiTTeelleemmeettrryy DDeevveellooppeerr
83
AProcotolMessage é uma classe abstracta que representa uma mensagem protocolar. Ela implementa o interface
é um template para processamento de mensagens:
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy
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
Para a geração uniforme de logs de actividade, o método Process do interface IProtocolMessage recebe parâmetro
erationSummary criado para este propósito.
A classe que coordena o processamento de uma mensagem interage com a fábrica de mensagens da seguinte
na Figura 67.
67 Template do Coordenador de Processamento de Mensagens
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 criar também uma implementação do padrão NULL.
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:
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
Para a geração uniforme de logs de actividade, o método Process do interface IProtocolMessage recebe parâmetro
A classe que coordena o processamento de uma mensagem interage com a fábrica de mensagens da seguinte
Template do Coordenador de Processamento de Mensagens
O coordenador de processamento de mensagens é uma implementação do padrão Template. Para o padrão ser
criar também uma implementação do padrão NULL.
Deste modo, a fábrica retorna um objecto processável que representa uma mensagem desconhecida.
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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).
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy
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.
Neste capítulo são mostrados os ecrãs prototipados, juntamente com a descrição da funcionalidade esperada.
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
Neste capítulo são mostrados os ecrãs prototipados, juntamente com a descrição da funcionalidade esperada.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoor
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
data do dado mais recente transmitido pela unidade traduz o estado da actualidade dos dados transmitidos.
Cálculo do estado de Dados
orr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
data do dado mais recente transmitido pela unidade traduz o estado da actualidade dos dados transmitidos.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy
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
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 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
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
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.
Deste modo, a equipa de software deixou de ser interrompida para esclarecer e verificar problemas de integração e
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.
Caso a data do dado mais recente da unidade esteja situado entre a última e a penúltima datas de comunicação
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
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 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.
Deste modo, a equipa de software deixou de ser interrompida para esclarecer e verificar problemas de integração e
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
101
para dispositivos móveis com o Android como base tecnológica e continuar a colaborar com ferramentas
opensource.
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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]
SSccrruumm AAddvviissoorr && iiTTeelleemmeettrryy DDeevveellooppeerr
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.