Ampliando o alcance da rede wifi com o WDS

Dependendo da casa é difícil ter um bom sinal de wifi em todos os cômodos. Paredes, banheiros e estruturas em metal atrapalham significativamente a abrangência do sinal, e nem sempre é ratico ter  vários cabos de rede espalhados pela casa para poder instalar diferentes APs. Nesses casos a solução é usar o recurso WDS junto com outro AP pra ampliar o acesso a sua rede. Com o WDS a comunicação entre os dois APs é feita via wifi.

Requisitos:

2 Access Point com recurso WDS e de preferência da mesma marca (já tentei fazer com  TP-Link TD-W8951ND e um AP Multilaser e não funcionou).

Como ficou a configuração:

TP-Link TD-W8951ND

TP-Link TL-WR710N

Em breve coloco a tradução.

Descomplicando o VoIP #05 (Configurando o Redfone)

O redfone é um gateway E1 e foi por um bom tempo referência no mercado. Mas o que aconteceu? A empresa faliu!! De qualquer forma, esse post pode ser útil para quem vai usar não somente produtos dessa marca. Num próximo post vou falar sobre o Aligera. Então, vamos...

A configuração do redfone é feita por meio de um script:

# wget support.red-fone.com/downloads/tools/setup-redfone.sh
# chmod +x setup-redfone.sh
# ./setup-redfone.sh

 opção 1
(download dos pacotes necessários. Em alguns casos durante os testes ocorria erro durante o download/instalação, mas em até 3 tentativas ia)

Checking for fb_flash_util: No
Checking for fonulator: No
Installing fb_flash_util
Checking for dependencies
Checking for libfb libraries: No
Downloading libfb libraries
Checking for libpcap: No.. downloading libpcap
Checking for libnet: No.. downloading libnet
Installing libfb... done
Downloading fb_flash_util
unpacking fb_flash-2.0.0.tar.gz
Installing fb_flash_util
fb_flash_util installed succesfully
Installing fonulator
Checking for dependencies
Checking for libfb libraries: found shared libfb libraries
Checking for argtable2: No.. downloading argtable2
Downloading fonulator
fonulator installed succesfully

 opção 2

Which Ethernet card will be used with the fonebridge?
1       eth0
2       eth1
Select Option [1-2]: 2
You selected eth1
Which port of the fonebridge will you be using for TDMoE traffic(1 or 2)? 1
Trying to query device
If there is no response after a few seconds please verify
that the foneBRIDGE2 is properly connected to eth1
foneBRIDGE2 found
You have a 2 port fonebridge
IP address of fonebridge port connected to eth1:  192.168.1.254
MAC address of fonebridge port connected to eth1: <MAC>
MAC address of eth1:                                <MAC>

 opção 3

As perguntas foram respondidas com a seguintes respostas, separadas por “,”:
yes, E (E1), cas (R2), hdb3, n(CRC, necessário verificar com a operadora se está habilitado na linha), 9 (R2), 1, <ENTER>, 1, y, <ENTER>, y, <ENTER>

As configurações feitas nessa opção foram baseadas em um link E1 da Oi tipo R2.

Opção 10

Com a execução do script acima é feito uma configuração inicial, mas ela necessita de ajustes para atender as particularidades do link e operadoras. Alguns arquivos seguiram os exemplos do OpenR2 (http://code.google.com/p/openr2/). Como resultado dos arquivos de configuração ficou assim:

/etc/redfone.conf

[globals]
fb=192.168.1.254
port=1
server=00:1a:4b:f4:92:3c
priorities=0,1,2,3

[span1]
framing=cas
encoding=hdb3

[span2]
framing=cas
encoding=hdb3

/etc/dahdi/system.conf

dynamic=ethmf,eth1/<MAC>/0,31,0
dynamic=ethmf,eth1/<MAC>/1,31,1

cas=1-15:1101
dchan=16
cas=17-31:1101
alaw=1-31

cas=32-46:1101
dchan=47
cas=48-62:1101
alaw=32-62


loadzone=br
defaultzone=br

/etc/dahdi/modules

#comentado o carregamento de alguns módulos desnecessários

# Rhino Dual and Quad-span T1/E1/J1 PCI Interface Card
#rxt1

# Rhino Single-span T1/E1/J1 PCI Interface Card
#r1t1

# Rhino 4/8/12/24 Channel Analog PCI Interface Card
#rcbfx

/etc/asterisk/chan_dahdi.conf

[trunkgroups]

[channels]
language=pt_BR
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
relaxdtmf=yes

group=0
signalling=mfcr2
mfcr2_variant=br
mfcr2_get_ani_first=no
mfcr2_max_ani=20
mfcr2_max_dnis=4
mfcr2_category=national_subscriber
mfcr2_logdir=span1Oi
mfcr2_logging=all
mfcr2_mfback_timeout=-1
callgroup=1
pickupgroup=1
context=from-pstn
channel => 1-10

group=1
signalling=mfcr2
mfcr2_variant=br
mfcr2_get_ani_first=no
mfcr2_max_ani=20
mfcr2_max_dnis=4
mfcr2_category=national_subscriber
mfcr2_logdir=span2Oi
mfcr2_logging=all
mfcr2_mfback_timeout=-1
callgroup=1
pickupgroup=1
context=from-pstn
channel => 32-41

No caso desse arquivo, na parte channel, só esta habilitado 10 canais (o link que usei de exemplo só tem 10 canais).

–------------------------- OU --------------------------------------

[trunkgroups]

[channels]
language=pt_BR
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
relaxdtmf=yes

group=0
signalling=mfcr2
mfcr2_variant=br
mfcr2_get_ani_first=no
mfcr2_max_ani=20
mfcr2_max_dnis=20
mfcr2_category=national_subscriber
mfcr2_logdir=span1Oi
mfcr2_logging=all
;mfcr2_mfback_timeout=-1
mfcr2_mfback_timeout=3000
mfcr2_metering_pulse_timeout=500
mfcr2_allow_collect_calls=no
callgroup=1
pickupgroup=1
context=from-pstn
channel => 1-10

group=1
signalling=mfcr2
mfcr2_variant=br
mfcr2_get_ani_first=no
mfcr2_max_ani=20
mfcr2_max_dnis=4
mfcr2_category=national_subscriber
mfcr2_logdir=span2Oi
mfcr2_logging=all
;mfcr2_mfback_timeout=-1
mfcr2_mfback_timeout=1500
mfcr2_metering_pulse_timeout=500
mfcr2_allow_collect_calls=no
callgroup=1
pickupgroup=1
context=from-pstn
channel => 32-41


Reiniciado o dahdi:

# /etc/init.d/asterisk stop
# /etc/init.d/dahdi restart

(pode acontecer de dar kernel panic, principalmente porque mexeu nos módulos, então basta reiniciar o servidor)

Para receber e efetuar ligações usando o redfone, no elastix foi adicionado um Tronco
DAHDI:
Name “Redfone” ,
Outbound Caller ID “<número do telefone com DDD>” (pode ficar em branco).
    Dialed Number Manipulation Rules: (Trunk Outgoing Dial Rules) – serve para adicionar automaticamente o código da operadora.
    (031) + 0 | [1-79]XXXXXXXXX
    (031119) + 0119 | NXXXXXXX
    (0031) + 00 | .

Descomplicando o VoIP #04 (Configurando o Elastix)

Seguindo o cenário definido no post anterior da série, vamos fazer as configurações no servidor. Configurar troncos, extensões, grupos, etc..

1) Instalação do elastix (Elastix-2.3). Não vou detalhar porque é uma instalação padrão. Configurar rede, senhas, etc., só seguir os passos.

2) Ao término da instalação basta fazer login. Acesse via browser o IP definido durante a instalação com o usuário e senha escolhidos.

3) O Elastix tem tradução para português, então pra quiser: vá em: System > Preferences > Language
Na aba PBX: 

4) Remover o tronco (trunk) padrão ZAP (padrão).
5) Na Opção Feature Codes foi desabilitado o 555.
6) Executado a configuração do gateway FXO (post pendente).
7) Executado a configuração do gateway E1 redfone (clique aqui).
8) Os ramais foram criados de acordo com a necessidade seguindo a política de ramais da organização (post pendente).
9) Configurar todos os DDRs de entrada em Inbound Routes seguindo o exemplo:
    “Description: RECEPCAO”
    “DID Number: 1600”
    “Set Destination: Ring Group > Recepcao <600>”
Obs.: A regra geral (que recebe tudo) tem o DID Number em branco.
10) Definir as rotas agora (Outbound Routes):

As regras são feitas com expressões regulares. As regras da expressão são:

X - qualquer digito entre 0 e 9
Z - qualquer digito entre 1 e 9
N - qualquer digito entre 2 e 9
[] - qualquer digito q esteja entre os [ ]. Exemplo: [135], qualquer digito entre 1, 3 e 5
. - qualquer conjunto de dígitos e em qualquer quantidade. O "." puramente significa que casa com qualquer coisa
| - o digito q estiver antes do | não será passado para fora do tronco. Exemplo: regra "0 | .", a pessoa digita 0191 no telefone, mas o que vai ser discado para a operadora é apenas 191

Exemplos de rotas:

Local
0 | 0800.
0 | 10XX
0 | 10XXX
0 | [1-4]XX
0 | [1-4]XXXXXXX

Celular
0 | 7XXXXXXX
0 | 8XXXXXXX
0 | 9XXXXXXX

Interurbano
0 | 0119XXXXXXXX
0 | 0XXXXXXXXXX

Internacional
0 | 00.

NumerosProibidos
0 | 0300.
0 | 0500.
0 | 0900.
0 | 102       

RecepcaoESeguranca
0 | 1XX

11) Para ter o recurso de permissão por ramal, adicione o modulo no FreePBX (PBX > Unembedded freePBX > Module Admin > Upload module): Custom Contexts 2.8.0rc1.1. (http://www.freepbx.org/forum/freepbx/users/hey-hey-check-it-out-custom-context-module). Para fazer o Upload de modulos é necessário ir em “Security” > “Advanced Security” > botar ON o “Enable direct access (Non-embedded) to FreePBX” e setar a senha para acesso, lembrando que não aceita todos os caracteres. Adicionado o modulo basta ir na listagem, selecionar e mandar instalar (seleciona install e depois clica em “process”). Depois de instalado a opção aparece no menu lateral do freePBX.
12) Por exemplo, criar os seguintes custom contexts.

1 Local (permissão nas rotas Local e RecepcaoESeguranca)
2 Local e Celular (permissão nas rotas RecepcaoESeguranca, Local e Celular)
3 Local Celular e Interurbano (permissão nas rotas RecepcaoESeguranca, Local, Celular e Interurbano)
4 Local Celular Interurbano e Internacional (permissão nas rotas RecepcaoESeguranca, Local, Celular e Interurbano e Internacional)
5 RecepcaoESeguranca (permissão na rota RecepcaoESeguranca)

Set All Allow, mas atentar aos itens:

ENTIRE Basic Internal Dialplan: Deny
ALL OUTBOUND ROUTES: Deny
NumerosProibidos: Deny

13) Instalado o áudio em português (áudio extraído do Disc-OS) e adicionado a pasta /var/lib/asterisk/sounds/ e complementado com alguns áudios gravados (ver http://www.slideshare.net/nasondasdoradio/configurao-do-stereo-mix-windows-7 – habilitar captura de áudio e http://www.oddcast.com/home/demos/tts/tts_example.php?sitepal – sintetizador de voz online). Audios adicionados a pasta pt_BR: cannot-complete-as-dialed.gsm (A ligação não pode ser completada), check-number-dial-again.gsm (Cheque o número e tente novamente). Para colocar o áudio em português é necessário dizer em cada extensão qual a linguagem vai ser usada (Language Code), no caso pt_BR.

Dissertação - Abordagem em Níveis para Definição de Arquiteturas de Referência

A prática da medição de software nas organizações envolve definir medidas, coletar e analisar dados para essas medidas com o propósito de apoiar a tomada de decisão. Além de normas e padrões que apoiam a definição do processo de medição e orientam sobre suas práticas, os recursos tecnológicos também são importantes para o sucesso de sua implementação.

Em uma organização, a escolha das soluções tecnológicas deve estar alinhada às necessidades organizacionais e serve como base para a execução dos processos (LAUDON e LAUDON, 2011). Dessa forma, soluções computacionais podem ser utilizadas para apoiar a execução do processo de medição. De fato, considerando a natureza das atividades de medição, o apoio computacional para sua realização é praticamente indispensável. Uma solução computacional pode ser descrita por meio de uma arquitetura que define um conjunto de componentes relacionados.

Como discutido no Capítulo 2, arquiteturas de referência podem ser utilizadas como base para a definição de soluções computacionais específicas. Quando se trata de uma definição de arquitetura de referência, os principais conceitos do domínio devem ser abordados em uma descrição clara dos componentes da arquitetura. A apresentação dos conceitos e dos componentes comumente é feita por meio de modelos/diagramas, assim as informações podem ser transmitidas de maneira objetiva e estruturada. Um ponto de partida para a elaboração de uma arquitetura de referência são as ontologias de domínio, pois são capazes de representar os conceitos do domínio de forma estruturada e sem ambiguidade (NAKAGAWA et al., 2009).

Neste capítulo a arquitetura de referência para medição de software proposta neste trabalho é apresentada. Antes de desenvolver a arquitetura de referência propriamente dita, foi definida uma abordagem para definição de arquiteturas de referência, que foi seguida neste trabalho. Essa abordagem é apresentada na seção 3.2. Na seção 3.3, é apresentada uma visão geral da arquitetura de referência e algumas informações sobre seu desenvolvimento. Nas seções 3.4 e 3.5 os componentes da arquitetura são detalhados e, finalmente, na seção 3.6 são apresentadas as considerações finais do capítulo.

Abordagem em Níveis para Definição de Arquiteturas de Referência

A necessidade de se dar especial atenção aos modelos no contexto do desenvolvimento de software tem sido reconhecida. Uma iniciativa em linha com essa afirmação é o paradigma de Engenharia Dirigida por Modelos (MDE – Model Driven Engineering) (FONDEMENT e SILAGHI, 2004), que advoga pelo uso de modelos em níveis de abstração diferentes e transformações dos modelos de um nível a outro para que um sistema seja desenvolvido. Uma abordagem proposta nesse contexto é a MDA (Model Driven Architecture) (OMG, 2003), onde um modelo independente de plataforma (PIM – Plataform Independent Model) é construído e usado como base para, a partir de transformações, gerar modelos de plataformas específicas (PSM – Plataform Specific Model), os quais são utilizados para a implementação de sistemas.

Com inspiração no paradigma de Engenharia Dirigida por Modelos (MDE), a abordagem para definição de arquiteturas de referência proposta e utilizada neste trabalho é organizada em níveis, onde em cada nível há um modelo em um nível de abstração diferente, do mais abstrato para o menos abstrato. Ainda, inspirada na abordagem de Arquitetura Dirigida por Modelos (MDA), a proposta faz distinção entre modelos independentes de plataforma e modelos de plataformas específicas. Mas, é importante ressaltar que, apesar de a abordagem definida ser inspirada em MDE e MDA, este trabalho não é uma proposta de MDE ou MDA e a definição das transformações que levam de um modelo para outro não fazem parte de seu escopo.

A abordagem definida é composta por cinco níveis, como mostra a Figura 3.1. Nela, as caixas retangulares representam os níveis da abordagem e as caixas com as bordas arredondadas localizadas no interior dos níveis representam os elementos que estão presentes em cada um deles. O nível de abstração diminui de cima para baixo. As setas indicam que o modelo de um nível é usado como base para a definição de modelo do nível seguinte. Após a figura a descrição de cada nível é apresentada.

Figura 3.1 - Visão geral da abordagem para definição da arquitetura para medição de software.

O primeiro nível da abordagem (Metaconceituação) diz respeito a modelos que descrevem objetos do mundo real, independentemente de domínio, os quais são representados por meio de ontologias de fundamentação. A função da ontologia de fundamentação é prover a conceituação genérica que será usada como base para definir a conceituação do domínio para o qual a arquitetura de referência será desenvolvida.

O segundo nível (Conceituação do Domínio) diz respeito a modelos que descrevem um domínio específico. Nesse nível encontra-se uma ontologia de domínio, cuja função é prover a conceituação do domínio no qual a arquitetura de referência será aplicada  Uma vez que a ontologia de domínio deve descrever o domínio da melhor maneira possível, ela deve ser uma ontologia de domínio de referência, ou seja, uma ontologia construída com o objetivo de fazer a melhor descrição possível de um domínio na realidade, em relação a um certo nível de granularidade e ponto de vista. Uma ontologia de domínio de referência é um tipo especial de modelo representando um modelo de consenso em uma comunidade. É uma especificação independente de solução, que visa fazer uma clara e precisa descrição das entidades do domínio para os propósitos de comunicação, aprendizado e solução de problemas (GUIZZARDI, 2007). A ontologia de domínio de referência deve ser definida com base na ontologia de fundamentação do nível anterior. O terceiro nível (Independente de Plataforma) diz respeito a modelos desenvolvidos para o domínio sem se preocupar com aspectos da plataforma, ou seja, aspectos relacionados a tecnologias específicas. Nesse nível está a arquitetura de referência, que é definida com base na ontologia de referência do nível anterior e tem função de servir como base para a definição de arquiteturas específicas. Ao se descrever uma arquitetura de referência, devem ser apresentados os componentes da arquitetura e seus papéis, os modelos que os descrevem, bem como qualquer outro artefato que auxilie na descrição da arquitetura de referência em um nível conceitual.  

O quarto nível (Plataforma Específica) diz respeito a modelos elaborados acrescentando-se aspectos tecnológicos ao modelo definido no nível anterior. Esses modelos são derivados a partir dos modelos conceituais definidos no terceiro nível, levando-se em consideração a utilização de tecnologias específicas. Além disso, alguns requisitos específicos também podem ser considerados, o que pode levar, por exemplo, à não utilização de algumas partes da arquitetura de referência  ou à necessidade de tratamento de aspectos não abordados na arquitetura de referência e que são necessários para a organização para a qual a arquitetura específica será definida. Assim, diferentes do nível anterior, modelos deste nível consideram, por exemplo, quais tecnologias de banco de dados serão utilizadas para implementar uma solução computacional para um determinado domínio. Consequentemente, os modelos estruturais elaborados no nível anterior devem ser adaptados de acordo com as tecnologias de banco de dados adotadas.

Por fim, o último nível (Aplicação) diz respeito às aplicações construídas a partir de arquiteturas para plataformas específicas definidas no nível anterior. Embora aplicações não sejam modelos, elas foram incluídas na abordagem, pois podem ser utilizadas para avaliar a arquitetura de referência proposta (MULLER, 2013).

O termo aplicação adotado no último nível da abordagem diz respeito às mais diversas soluções computacionais que podem ser produzidas. Uma ferramenta ou uma solução computacional envolvendo vários sistemas são exemplos de aplicações que poderiam ser produzidas nesse nível.

A abordagem descrita nesta seção foi utilizada para o desenvolvimento da arquitetura de referência proposta. No nível 1, foi utilizada UFO (Unified Foundational Ontology) (GUIZZARDI, 2005), uma ontologia de fundamentação que modela entidades do mundo real de forma genérica e que foi descrita no Capítulo 2. No nível 2, foi utilizada a Ontologia de Referência para Medição de Software (BARCELLOS, 2009; BARCELLOS et al., 2013), uma ontologia de domínio construída com base em UFO e que descreve o domínio de medição de software, incluindo aspectos relacionados tanto à medição tradicional quanto em alta maturidade. Essa ontologia também foi apresentada no Capítulo 2. Na próxima seção é apresentada uma visão geral da Arquitetura de Referência para Medição de Software proposta.

Dissertação - Arquiteturas para Medição de Software

Conforme dito no capítulo de Introdução, uma arquitetura é uma estrutura lógica em que os componentes são organizados e integrados (ZACHMAN, 1987). Comumente representadas por diferentes visões (especificações e esquemas), as arquiteturas correspondem a estruturas e direcionamentos a serem seguidos durante a implementação de sistemas. Uma arquitetura pode se constituir em diferentes níveis de detalhes, podendo ser mais generalista, representando um conjunto de sistemas, ou mais específica e detalhada, representando um sistema específico. O número de visões e o nível de abstração determinam o quão específica é uma arquitetura.

Nos últimos anos, um novo conceito relacionado à arquitetura tem se feito presente na literatura de Engenharia de Software: arquitetura de referência.

Arquiteturas de Referência

Segundo Muller (2013), uma arquitetura de referência captura a essência da arquitetura de um conjunto de softwares ou de um domínio e possui o propósito de guiar o desenvolvimento de arquiteturas para novos sistemas ou atualizações. Diferente do conceito mais generalista de arquitetura puramente dita, uma arquitetura de referência tem o propósito evidente de reúso.

As arquiteturas de referência proveem uma taxonomia comum, uma visão arquitetural compartilhada, uma modularização e um contexto unificado (MULLER, 2013). A taxonomia contribui em facilitar a comunicação (por exemplo, por meio de um modelo de domínio). A visão arquitetural concentra e alinha esforços de múltiplas equipes quanto à especificação de arquiteturas. A modularização ajuda a dividir o esforço, permitindo que toda ou apenas parte seja usada, e o contexto único assegura uma posterior integração na evolução do sistema.

Assim como arquiteturas de software em geral, arquiteturas de referência podem representar diferentes visões e considerar diferentes níveis de detalhe e de abstração. Portanto, arquiteturas de referência podem ser definidas por meio de diferentes artefatos e com diferentes níveis de detalhes. Consequentemente, um desafio ao se definir uma arquitetura de referência é saber o quão suficiente ela deve ser em sua composição e descrição.

Segundo Muller (2013), definir uma arquitetura que seja compreendida pelas partes interessadas e que aborde as principais questões do domínio são alguns dos direcionamentos que podem ser seguidos para construir uma arquitetura de referência de qualidade.

No entanto, conforme argumenta Nakagawa et al. (2009), estabelecer arquiteturas de referência não é uma tarefa trivial. Capturar a essência de um domínio requer um levantamento bem elaborado e uma correta organização e apresentação das informações. Nesse sentido, o uso de ontologias pode ser uma boa abordagem.

 Nakagawa et al. (2009) investiga os impactos do uso de ontologias na elaboração de arquiteturas de referência e, como resultado, destaca que a principal contribuição das ontologias está no apoio ao levantamento de informações e entendimento do domínio. O estudo também aponta que as visões de arquiteturas tradicionais não são suficientes para representar arquiteturas de referência, uma vez que, de forma geral, não preveem elementos para explicar cada conceito presente na arquitetura. 

O processo de desenvolvimento de uma arquitetura de referência contém quatro atividades principais, conforme mostra a Figura 2.9 (GALSTER e AVGERIOU, 2011; MULLER, 2013; NAKAGAWA et al., 2009).

Figura 2.9 - Processo de desenvolvimento de uma arquitetura de referência (adaptado de (NAKAGAWA et al., 2009)).

A primeira atividade consiste no levantamento de informações a respeito do domínio a ser tratado. Nesse momento devem ser realizadas investigações e pesquisas para se obter a maior quantidade possível de informações sobre o domínio em foco. O próximo passo consiste na definição da arquitetura de referência propriamente dita, a qual deve ser descrita através de documentos e modelos, representando as diferentes visões da arquitetura. Em seguida, ocorre a instanciação da arquitetura de referência em arquiteturas de sistemas. Por fim, é realizada a avaliação da arquitetura, a fim de avaliar, dentre outros, se sua descrição é satisfatória para que os utilizadores compreendam o domínio e as visões descritas, se a modularização permite a utilização da arquitetura em partes e se a arquitetura reflete o estado atual do domínio. Os resultados das avaliações de instâncias de uma arquitetura de referência fornecem informações que devem ser utilizadas para adequá-la.

Conforme comentado anteriormente, arquiteturas de referência são definidas principalmente visando à reutilização. Dessa forma, uma vez que uma arquitetura de referência tenha sido definida, avaliada e considerada adequada, espera-se que ela seja utilizada como base para a definição de arquiteturas de software para diversos sistemas. A Figura 2.10 apresenta a visão de Muller (2013) sobre o processo de utilização de arquiteturas de referência.

Figura 2.10 - Esquema de funcionamento da instanciação de uma Arquitetura de Referencia (MULLER, 2013).

Uma arquitetura de referência é utilizada como base para a definição da arquitetura de um ou mais sistemas. As diversas arquiteturas definidas para vários sistemas compõem uma família de arquiteturas e é provável que, embora essas arquiteturas apresentem particularidades, elas possuam uma parte compartilhada, que é a parte presente na arquitetura de referência. As arquiteturas de software definidas são, então, utilizadas como base para a implementação dos sistemas, os quais são utilizados no mundo real. Os resultados da utilização dos sistemas podem prover feedback capaz de nutrir a arquitetura de referência com informações essenciais que podem ser utilizadas para evoluir continuamente a arquitetura de referência.

Dissertação - Medição de Software

Segundo Dumke (2010), medição é o processo pelo qual números ou símbolos são atribuídos a propriedades de entidades do mundo real de forma a descrevê-las. Ao longo das atividades de engenharia de software, diversas medições podem ser realizadas visando à obtenção de informações relevantes, como, por exemplo, o tamanho dos projetos, os custos de desenvolvimento e a quantidade de defeitos.

No contexto de projetos de software, a medição pode auxiliar a elaboração de planos realísticos e pode prover informações úteis ao acompanhamento do alcance aos objetivos, à identificação de problemas e à tomada de decisões informadas (McGARRY et al., 2002). No contexto organizacional, a medição pode auxiliar na análise do desempenho dos processos e apoiar o estabelecimento de metas factíveis, bem como a identificação de ações que visem melhorar a competitividade da organização (TARHAN e DEMIRORS, 2006).

Embora os benefícios obtidos a partir da implementação da medição sejam muitos, realizar medição demanda esforço e, consequentemente, há custos envolvidos. Similar a outras atividades de controle, estima-se que a medição corresponda de 0.3% a 1% do esforço desprendido no desenvolvimento. Sendo que, no início do uso da medição pela organização, essa porcentagem é mais elevada devido à estruturação inicial requerida: realização de treinamentos, elaboração de templates, definição dos mecanismos de coleta e implantação de ferramentas (DUMKE e EBERT, 2010).

Dumke e Ebert (2010) defendem que a eficiência da medição de software está fortemente relacionada ao apoio de ferramentas associadas a todo o processo de medição. Card et al. (2008), por sua vez, afirmam que apesar de ferramentas serem muito importantes para apoiar a realização do processo de medição, o uso delas não garante o sucesso de um programa de medição. Segundo McGarry et al. (2002), o sucesso de um programa de medição está diretamente relacionado a dois fatores: (i) a coleta, análise e divulgação dos resultados das medições devem estar diretamente relacionadas às informações requeridas para as tomadas de decisão; e (ii) o processo de medição deve ser bem estruturado e repetível.

Existem diversos padrões que orientam sobre o processo de medição de software, dentre eles: a ISO/IEC 15939 (ISO/IEC, 2007), a ISO/IEC 12207 (ISO/IEC, 2008), o Std. 1061 (IEEE, 1998), o PSM – Practical Software Measurement (McGARRY et al., 2002), o CMMI (SEI, 2010) e o MR-MPS-SW (SOFTEX, 2012). Em linhas gerais, o processo de medição de software inclui as seguintes atividades: planejamento da medição, execução da medição e avaliação da medição (ISO/IEC, 2008), conforme ilustra a Figura 2.1.

Figura 2.1 - Atividades gerais do processo de medição de software.

No planejamento da medição, com base nos objetivos e necessidades da organização, são definidas as entidades (processos, produtos, etc.) que serão consideradas para medição, quais de suas propriedades (custos, defeitos, etc.) serão mensuradas e quais medidas serão utilizadas. Para cada medida deve ser estabelecida uma definição operacional, que detalha aspectos relacionados à coleta e análise de dados. Nesse contexto, Dumke e Ebert (2010) destacam a importância de se ter definições operacionais precisas, buscando-se evitar que pessoas diferentes entendam a medida de maneiras diferentes e realizem medições inconsistentes. Os resultados do planejamento da medição são registrados no Plano de Medição.

Existem alguns métodos que auxiliam as organizações no planejamento da medição, visando à identificação de medidas que sejam realmente úteis. De acordo com BASILI e Green (1994) a definição de medidas úteis depende da identificação dos fatores críticos que são capazes de determinar se os objetivos de negócio serão ou não alcançados. Nesse sentido, uma das abordagens mais conhecidas é o GQM (Goal Question Metric) (BASILI et al., 1994), que considera que, para cada objetivo estabelecido, é possível determinar questões cujas respostas estão associadas a medidas.  Algumas variações desse método são o GQ(I)M (Goal Question (Indicator) Measure) (GOETHERT e FISHER, 2003), que,  baseado no entendimento de que identificar questões e medidas sem visualizar um indicador muitas vezes não é suficiente, propõe o alinhamento de medidas e indicadores com os objetivos, e o GQM*Strategies (BASILI et al., 2007), que acrescenta um conjunto de extensões no topo do método GQM, tornando explícitos os objetivos de negócio, as estratégias e os objetivos de software.

Após ser planejada, a medição pode ser executada. A execução consiste em coletar e armazenar os dados para as medidas definidas, de acordo com suas definições operacionais especificadas na etapa de planejamento.

Em relação ao armazenamento dos dados da medição Braungarten et al. (2005) afirmam que ele pode ser feito em planilhas eletrônicas, bancos de dados ou repositórios. De acordo com os autores, devido à simplicidade e baixo custo, as planilhas são usadas em grande parte das organizações. No entanto, elas não são adequadas a médio ou longo prazo, pois a consistência estrutural não pode ser assegurada e o acesso aos dados pode ser dificultado quando novas medidas ou mais dados são necessários. Bancos de dados são mais eficientes que planilhas, especialmente quando se trata de um grande volume de dados. Apesar dessa vantagem, tipicamente requerem maior investimento para construção e manutenção. Além disso, às vezes, organizações utilizam vários bancos de dados para tratarem diferentes aspectos da medição, o que pode levar ao comprometimento da integridade dos dados e a redundâncias que podem afetar a obtenção de informações corretamente. Repositórios, por sua vez, consideram uma visão mais ampla da medição do que bancos de dados e podem lidar com questões de integração de dados para permitir armazenamento e acesso adequados. Em contrapartida, a construção e o gerenciamento de repositórios costumam exigir esforço ainda maior que o empregado nos bancos de dados.

Com os dados coletados e armazenados, diferentes análises podem ser realizadas. A análise dos dados fornece informações para a tomada de decisão, favorecendo a identificação e execução de ações apropriadas. Durante a análise, frequentemente os dados são representados graficamente, a fim de propiciar uma melhor visualização e favorecer a análise dos dados. Gráficos podem representar tendências de dados, variações e tornar as relações entre diferentes medidas mais claras. Segundo McGarry et al. (2002), os gráficos mais comumente utilizados na medição de software são o gráfico em linha, usado para medidas ao longo do tempo, o gráfico em barras, usado para contagem de um grupo de componentes ou eventos,  e o gráfico de dispersão, usado para relação entre dois fatores. Como resultado das análises algumas ações podem ser identificadas, como, por exemplo, estender prazos, adicionar recursos, mudar a abordagem de desenvolvimento e realocar recursos (McGARRY et al., 2002).

Modelos de maturidade, tais como o CMMI (SEI, 2010) e MR-MPS-SW (SOFTEX, 2012) incluem medição como um dos processos fundamentais para a melhoria de processos. No CMMI a medição é introduzida no nível 2, enquanto que no MR-MPS-SW isso ocorre no nível F. A medição realizada nesses níveis é dita medição tradicional e tem como principal objetivo apoiar o gerenciamento de projetos e processos por meio da comparação entre valores planejados e valores realmente praticados. Nos níveis mais elevados de maturidade (níveis 4 e 5 do CMMI e níveis B e A do MR-MPS-SW) a medição tradicional não é mais suficiente. Nesses níveis é necessário realizar o controle estatístico dos processos críticos, a fim de conhecer seu comportamento, determinar seu desempenho em execuções anteriores e prever seu desempenho em projetos em curso e futuros, verificando se são capazes de alcançar os objetivos estabelecidos. Essa medição é chamada medição em alta maturidade (BARCELLOS et al., 2013).