Técnicas e Ferramentas para Gerenciamento

de Mudança

Conteudista: Prof. Me. Luiz Carlos Machi Lozano

Revisão Textual: Esp. Jéssica Dante

Objetivos da Unidade:

Explanar as principais técnicas e ferramentas utilizadas durante o processo de

manutenção de software, visando medir características de manutenção, visões,
gerência de configuração e análise de impacto das alterações.

ʪ Material Teórico

ʪ Material Complementar

ʪ Referências
TEMA 1 de 3

ʪ Material Teórico

Medindo as Características da Manutenção

Podemos discutir várias características de sistemas que podem facilitar ou não nosso
entendimento, melhoramento e correção. Esses fatores são utilizados para avaliar o software
quando ele é disponibilizado, podendo assim ser prevista a probabilidade de haver fácil
manutenção.

No processo de manutenção do software, medidas devem ser tomadas para orientar as nossas
atividades, auxiliando na avaliação de impacto de uma alteração ou mesmo avaliando méritos
sobre as modificações propostas (PFLEEGER, 2004).

Quando falamos em facilidade de manutenção, não estamos falando apenas no código, pois essa
abordagem vai muito além disso, incluindo também os seguintes itens:

Documentos de especificação do projeto;

Documentos de especificação do plano de testes.

Devido a isso, são necessárias medidas para a avaliação de facilidade de manutenção para todos
os produtos que se pretende fornecer.

A facilidade de manutenção, segundo Pfleeger (2004), pode ser fornecida de duas maneiras:

Ponto de vista externo do software;

 Ponto de vista interno do software.

A facilidade de manutenção é um atributo (propriedade) externo ao software; ela é altamente

dependente de alguns aspectos, dentre eles:

Dependente do produto;

Depende da equipe que é responsável pela manutenção;

Depende da documentação;

Depende das ferramentas de suporte técnico;

Depende do uso do software em questão.

Você Sabia?
Não se mede se um sistema possui fácil manutenção sem a realização
de seu monitoramento em um ambiente específico de uso
(SOMMERVILLE, 2016).

É fato que queremos medir a facilidade de manutenção de um sistema antes que ele seja
entregue ao cliente final, pois assim conseguimos ter uma boa noção de quais recursos serão
necessários para resolver qualquer problema que possa acontecer. Nesse caso utilizam-se os
atributos internos do software, que nada mais são do que os atributos relacionados com a
estrutura do sistema. 

Devido a essa maneira de realizar o processo não ser uma medida direta, deve-se ponderar a
praticidade da abordagem indireta com a precisão da abordagem externa (PFLEEGER, 2004).

Visões da Manutenibilidade
Para realizar a medição da manutenibilidade, focando no tempo médio para a resolução de um
problema, é necessário realizar registros cautelosos de algumas informações referentes a cada
problema:

O momento em que o problema é relatado;

Qualquer perda de tempo devido à demora por parte do setor administrativo;

O tempo exigido para analisar o problema;

O tempo requerido para especificar quais mudanças devem ser feitas;

O tempo necessário para fazer essas mudanças;

O tempo necessário para testar as mudanças;

O tempo necessário para documentar as mudanças.

 Figura 1 – Tempo médio para corrigir defeitos por área do
sistema
Fonte: Adaptada de PFLEEGER, 2004, p. 395

A imagem anterior demonstra o tempo médio gasto na correção de problemas em vários

subsistemas de software em uma empresa de grande porte situada na Inglaterra. Essas
informações são muito importantes para fornecer subsídios para identificação de subsistemas
que causam a maioria dos problemas e assim planejar quais ações/atividades serão tomadas
para o planejamento da manutenção preventiva (PFLEEGER, 2004).

Acompanhar o tempo médio para a correção de problemas utilizando gráficos é uma forma de
verificar se o sistema está se tornando mais manutenível ou não, porém outras medidas podem
ser utilizadas:

A razão do tempo total de implementação da mudança pelo

número total de mudanças implementadas;
 O número de problemas não resolvidos;

O tempo gasto em problemas não resolvidos;

A porcentagem de mudanças que introduzem novos defeitos;

O número de componentes modificados para implementar uma mudança.

Juntando todas essas medidas temos um indicador de grau da atividade de manutenção e

efetividade do processo de manutenção (PFLEEGER, 2004).

Diversos pesquisadores já propuseram medidas para atributos internos relacionados à

manutenibilidade. Sempre as medidas de manutenção estão relacionadas com a complexidade,
portanto, quanto mais complexo for o sistema, maior será o esforço para sua manutenção.

Uma das medidas mais utilizadas na manutenção de sistemas é o número ciclomático. O número
ciclomático considera o aspecto da complexidade estrutural do código-fonte de um sistema,
fazendo a medição do número de caminhos linearmente existentes ao longo do código. Utiliza
como base o conceito de grafos e é calculado convertendo-se o código em seu diagrama de fluxo
de controle equivalente, utilizando-se das propriedades do grafo para gerar sua medida
(PFLEEGER, 2004).

Existem outras formas de realizar a medida da manutenibilidade de um sistema. Diversas

empresas pelo mundo criaram métodos por meio de estudos que conseguiram realizar suas
previsões. 

Segundo Pfleeger (2004), a facilidade de manutenção pode ser modelada utilizando-se três
dimensões:

A estrutura de controle;

A estrutura de informações;
 A tipografia, nomeação e comentário do sistema do qual se está fazendo a
manutenção.

Elas definem medidas para cada dimensão e as combinam em um índice de manutenibilidade

para o sistema inteiro. Esse índice de manutenibilidade foi utilizado em 1994 pela HP (Hewlett-
Packard) na avaliação de vários sistemas de software.

Primeiramente esse índice foi ajustado se baseando em um grande número de medidas,

utilizando-se um índice polinomial apropriado se calculou o número ciclomático, linhas de
código, número de comentários e uma medida de esforço (PFLEEGER, 2004).

Na sequência, o índice polinomial foi aplicado a mais de 700 componentes contendo mais de 200
mil linhas de código em linguagem de programação C. Como resultado, a análise de
manutenibilidade disponibilizou uma classificação de componentes que ajudou a HP a distinguir
aqueles que possuíam uma difícil manutenção (PFLEEGER, 2004).

Também utilizaram polinômios para realizar a comparação entre dois sistemas que possuíam
tamanhos, plataformas e linguagens semelhantes, obtendo resultados para auxiliar nas
decisões sobre desenvolvimento e compras, direcionando componentes para manutenção
preventiva e perfectiva (PFLEEGER, 2004).

Outra forma de se realizar a medição da manutenibilidade de um sistema é por meio da análise de

árvore de classificação, que é uma técnica estatística e utiliza medidas dos produtos que são
melhores para realizar a previsão de erros de interface que provavelmente irão ocorrer durante a
manutenção do sistema. Segundo Pfleeger (2004), a árvore de decisão é resultante da análise de
classificação dos seus dados e sugere restrições mensuráveis com base em dados históricos:

Entre 4 e 8 revisões durante o projeto e pelo menos 15

vinculações de dados indicam grande probabilidade de se
encontrar erros de interface;

Os problemas de interface são prováveis em um componente cuja função primária é

o gerenciamento de arquivos, no qual houve, nove revisões durante o projeto.
As sugestões são específicas para um conjunto de dados e não pretende ser geral para qualquer
empresa, porém, a técnica pode ser aplicada a qualquer sistema de banco de dados com
informações de medições.

Uma maneira de reduzir o esforço gasto na etapa de manutenção é realizar a construção do

sistema com qualidade desde o início. Tentar forçar um bom projeto e uma boa estrutura em um
sistema já existente não se torna tão produtivo quanto desenvolver o sistema de forma correta
desde o início, porém, além de boas práticas, existem várias técnicas que aprimoram a qualidade
e a compreensão de um sistema. Dentre elas podemos mencionar:

Gerência de configuração;

Análise de impacto;

Ferramentas automatizadas para manutenção.

Gerência de Configuração
É impossível evitar alterações durante a construção de um sistema, pois as modificações são em
grande parte o motivo de desentendimento dentro das equipes de desenvolvimento e quando
aparecem e não são analisadas de forma correta, antes de sua implementação, podem ocasionar
na falta de controle da equipe sobre o projeto (PRESSMAN; MAXIM, 2016).

Um sistema vive em constante mudança, portanto essa é uma característica bem comum a todos
os softwares. As empresas necessitam de alterações em seus requisitos de software durante todo
o ciclo de vida de um sistema, sejam por adaptações por mudanças em regras de negócio ou
mesmo em correções de bugs que surgem durante o uso do sistema (SOMMERVILLE, 2016).

Para garantir que as modificações serão implementadas em um software de forma controlada e

mantendo organização, por meio da Engenharia de Software utiliza-se um conjunto de
processos, controlados por ferramentas e sendo gerenciadas pelo gerenciamento de mudanças,
que por sua vez tem o objetivo de assegurar que o software possa manter uma evolução saudável,
ou seja, mantendo-se a organização e o controle de suas modificações durante o seu ciclo de
vida, priorizando as modificações com urgência e que possuam uma melhor relação de
custo/benefício (SOMMERVILLE, 2016).

O gerenciamento de configuração e mudanças é um processo que realiza a análise entre

custo/benefício de uma alteração, tendo como principal característica o controle de quais
componentes serão alterados e realizando a aprovação das alterações. O gerenciamento de
mudanças é implementado em uma empresa no momento em que o sistema é colocado em
operação, ou seja, quando ele passa a ser utilizado pelos usuários em um ambiente real
(SOMMERVILLE, 2016).

O gerenciamento de mudanças pode estar atrelado a diversas vertentes, possuindo diferentes

configurações de acordo com o software ou empresa, visto que empresas pequenas não utilizam
processos complexos, que por sua vez são utilizados nas empresas de grande porte. Segundo
Sommerville (2016), os processos de gerenciamento de configuração, independentemente do
tamanho da empresa, devem englobar:

Verificação das mudanças;

Levantamento de custos das mudanças;

Aprovação das mudanças;

Validação das mudanças.

Existem diversas ferramentas que podem ser utilizadas para apoiar o processo de
gerenciamento de mudanças em uma empresa, desde ferramentas simples, que servem apenas
para realizar o monitoramento de bugs ou mesmo sistemas integrados (SOMMERVILLE, 2016).

Alguns sistemas permitem que qualquer usuário possa abrir chamados relatando defeitos ou até
mesmo sugestões de futuras modificações no sistema, monitorando também a equipe de
manutenção e desenvolvimento em seu retorno aos chamados (SBROCCO; MACEDO, 2012).
O processo de gerenciamento de configuração e mudanças se inicia no momento em que uma
parte interessada realiza a solicitação de uma alteração, mencionando todas as modificações
desejadas no software. A solicitação pode ser realizada de forma manual ou automatizada, porém
se utiliza um formulário de solicitação de mudança, chamado CRF (Chang Request Form)
(SOMMERVILLE, 2016).

O formulário de solicitação de mudanças, com todas as informações de alterações desejadas são

distribuídos a todos os envolvidos no processo, e assim que o processo caminha novas
informações podem ser inseridas neste formulário (SOMMERVILLE, 2016). 

O formulário de solicitação de mudanças possui o registro com o histórico da modificação e

pode também possuir um detalhamento mais técnico descrito pelos desenvolvedores sobre uma
possível solução para a solicitação (SOMMERVILLE, 2016).

Logo depois do envio da solicitação, ela deve ser analisada, conferida e validada por um
conferente, que por sua vez é uma pessoa da equipe do cliente, suporte ou mesmo do time de
manutenção, em caso de ser uma modificação de ordem interna.

Uma solicitação também pode ser rejeitada e sua rejeição pode se dar por diversos motivos,
dentre eles:

Problema já resolvido anteriormente;

Implementação já realizada;

Entendimento equivocado sobre funcionalidades do sistema.

Nas empresas de Tecnologia da Informação utilizam-se metodologias ágeis em grande escala

para o tratamento dos diversos processos existentes, inclusive durante os processos de
manutenção. Nesse caso o próprio cliente, por meio de seus representantes, pode auxiliar a
equipe de manutenção no que deve ser priorizado, essa técnica é muito eficaz em sistemas que
atendem apenas um cliente, porém em sistemas mais genéricos que atendem a um número
maior de clientes ao mesmo tempo isso pode ser um grande problema (SOMMERVILLE, 2016).
Após uma solicitação de mudança ser validada pela empresa, deve-se calcular algumas métricas
como custo e tempo que será necessário. Essa tarefa deve ser realizada pela equipe de
manutenção. Também deve ser realizada uma minuciosa análise de impactos, pois uma
mudança pode causar diversos outros problemas dentro de um sistema. 

A análise de impacto realiza o mapeamento de todos os componentes existentes no software que

podem de alguma maneira sofrer alguma interferência pela modificação, podendo gerar custos
extras e novo prazo para solicitação (SOMMERVILLE, 2016).

Importante!
Uma técnica importantíssima utilizada para realizar a análise de
impacto que uma alteração pode causar é a matriz de rastreabilidade.
Por meio da matriz de rastreabilidade é realizado um cruzamento entre
a relação que os requisitos possuem entre si ou com outros aspectos do
software. Com a matriz de rastreabilidade é possível localizar
rapidamente quais setores do sistema serão afetados por uma mudança
(PAULA FILHO, 2019).

Depois de uma análise criteriosa, decide-se se a mudança será interessante para a empresa, ou
seja, se ela não causará prejuízos. Em muitos casos existe um comitê que é responsável por
realizar todo o controle das mudanças, esse comitê é chamado de grupo de desenvolvimento do
produto.
O grupo de desenvolvimento do produto possui como principal função a responsabilidade pelas
tomadas de decisões sobre as possíveis mudanças, porém esse comitê apenas é invocado em
solicitações mais complexas, portanto, em correção de pequenos problemas o comitê não deve
ser ativado.

Segundo Sommerville (2016), o grupo de desenvolvimento do produto é responsável pela

análise de solicitações de alterações, porém se baseiam em cinco fatores:

O resultado de não realizar uma alteração;

As vantagens de uma alteração;

A quantidade de usuários que serão afetadas pela modificação;

Os custos;

O ciclo de lançamento do sistema.

Podemos definir como configuração de software os itens que possuem todas as informações
desenvolvidas no processo de desenvolvimento de software (PRESSMAN; MAXIM, 2016).

Importante!
Os itens de configuração de software, chamados também de SCIs, do
inglês (Software Configuration Items), podem gerar outros itens de
configuração de software, segundo (PRESSMAN; MAXIM, 2016), a
primeira lei da Engenharia de Sistemas diz: “Não importa onde você
esteja no ciclo de vida do sistema, o sistema mudará, e o desejo de
alterá-lo persistirá por todo o ciclo de vida”.

As alterações podem surgir de diferentes aspectos, dentre os mais comuns podemos citar os
seguintes:

Novos modelos de negócio ou mesmo novas condições

existentes no mercado;

Novas demandas por parte dos clientes;

Reestruturação da empresa, ocasionando modificações nas prioridades;

Custo;

Tempo.

Quando falamos em gerenciamento de configuração de software, podemos defini-lo de forma

mais simples como um grupo de atividades que são realizadas com intuito de gerenciar
alterações durante o ciclo de vida de um software, visando garantir a qualidade de um sistema de
software (PAULA FILHO, 2009).

Dentro de um modelo de gerenciamento de configuração de software mais tradicional, onde o

gerenciamento de configuração foca nos procedimentos e políticas a serem aplicadas, um
engenheiro de software deve ter a responsabilidade de desenvolver e manter um artefato de
software e o cliente na utilização do sistema (PRESSMAN; MAXIM, 2016).
Podemos imaginar um sistema que possui mais de dez mil linhas de código-fonte e a equipe de
manutenção possua quatro desenvolvedores, cada um possuindo um papel e sua respectiva
tarefa. Nesse cenário o gerente do projeto possui o foco em manter o prazo e os custos
projetados no escopo do projeto, monitorando o progresso da equipe de manutenção e tomando
ações necessárias quando algum problema é reportado (PRESSMAN; MAXIM, 2016).

A responsabilidade de um gerente de configuração de software é garantir que procedimentos e

políticas definidas no projeto para o desenvolvimento, modificação e bateria de testes sejam
minuciosamente realizados, implementando ferramentas de controle para realizar o
acompanhamento e a validação das modificações (PAULA FILHO, 2009).

Por sua vez, os engenheiros de software visam assegurar que o trabalho será realizado de forma
eficaz, sem atritos e utilizando também em alguns casos ferramentas automatizadas para o
controle dos artefatos de software (PRESSMAN; MAXIM, 2016).

Em muitos casos, diversas versões do sistema podem estar sendo trabalhadas ao mesmo tempo,
portanto, as modificações podem gerar diversos arquivos. Existem ferramentas automatizadas
que possibilitam realizar a junção dos arquivos, tratando conflitos e gerando diversas versões
das alterações (PAULA FILHO, 2019).

A tarefa do cliente é realizar a utilização do software, mas deve seguir regras e alguns padrões de
utilização. Sua utilização do controle de configuração e mudanças é apenas para realizar
possíveis solicitações (PRESSMAN; MAXIM, 2016).

A gerência de configuração deve se atentar a quatro elementos, de acordo com Pressman e

Maxim (2016), são eles:

Componente: ferramentas acopladas;

Processo: tarefas envolvidas;

Humano: pessoas envolvidas;

Construção: ferramentas envolvidas.

Falamos um pouco sobre a análise de impacto e a matriz de rastreabilidade, porém ela deve
englobar os seguintes aspectos:

Assegurar que a equipe de desenvolvimento ou manutenção de

software utilize técnicas para reduzir o impacto que uma ação
realizada em seu trabalho possa interferir no trabalho de
outras pessoas;

Assegurar que a equipe de desenvolvimento ou manutenção de software utilize

técnicas para reduzir o impacto que uma ação realizada no trabalho de outras
pessoas possa interferir em seu próprio trabalho.

Análise de Impacto

Saiba Mais
A análise de impacto utiliza-se da matriz de rastreabilidade para
mapear cruzamentos entre componentes do próprio projeto por meio
dos requisitos, tendo como principal função o detalhamento de todo o
trabalho para o entendimento de possíveis efeitos que uma mudança
poderá causar em um outro componente do sistema (PRESSMAN;
MAXIM, 2016).
Ao estudar a matriz de rastreabilidade, Pressman e Maxim (2016) mencionam que a análise de
impacto é responsável por realizar três tarefas fundamentais:

Rede de impacto;

Gerenciamento de impacto adiante;

Gerenciamento de impacto retroativo.

A Rede de impacto é a tarefa que é responsável por localizar os componentes de uma equipe de
desenvolvimento e todos que podem afetar ou ser afetados pelas alterações realizadas no
sistema (PRESSMAN; MAXIM, 2016).

O Gerenciamento de impacto adiante é a tarefa que é capaz de realizar a avaliação do impacto de

uma modificação realizada por um desenvolvedor sobre outros membros da rede de impacto,
mantendo todos informados sobre os impactos dessa modificação (PRESSMAN; MAXIM, 2016). 

Por fim, o gerenciamento de impacto retroativo é uma tarefa que é capaz de analisar todas as
modificações produzidas por outros componentes da equipe de manutenção ou
desenvolvimento do sistema e o impacto que poderá ocasionar em seu próprio trabalho,
agregando ferramentas e processos para mitigar tais impactos (PRESSMAN; MAXIM, 2016).

Ferramentas Automatizadas para Manutenção

Realizar o acompanhamento do status de todos os componentes e testes é uma tarefa muito
difícil, porém existem muitas ferramentas automatizadas que podem auxiliar na manutenção de
software, a seguir iremos mencionar alguns tipos de ferramentas:

Editores de texto;
 Comparadores de arquivos;

Compiladores e linkers;

Ferramentas de depuração;

Geradores de referência cruzada;

Analisadores estáticos de código;

Repositórios de gerência de configuração.

Os editores de texto podem ser úteis de diversas formas, primeiramente podem copiar um
código ou sua documentação de um local para outro, evitando assim erros que podemos gerar
quando duplicamos um texto. Na sequência um editor de texto pode acompanhar alterações
relativas a um arquivo baseline, armazenado separadamente, armazenando hora e data em que
cada entrada de texto ocorreu e, se necessário, proporcionam um meio de retornar a uma versão
anterior (PFLEEGER, 2004).

Os comparadores de arquivos são ferramentas muito úteis durante a manutenção de software,

visto que como o próprio nome diz, ele realiza a comparação de dois arquivos e como resultado
apresenta a diferença. Esse tipo de ferramenta é utilizada para assegurar que dois programas que
parecem idênticos realmente são (PFLEEGER, 2004).

Já os compiladores e linkers apresentam recursos que simplificam a manutenção e o

gerenciamento de configuração, um compilador realiza a verificação de falhas de sintaxe no
código-fonte e em muitas vezes indica a localização e o tipo da falha (PFLEEGER, 2004).

Quando um código é compilado de forma correta, o linker vincula o código a outros

componentes necessários para a execução do programa.

As ferramentas de depuração ajudam na manutenção, pois permitem acompanhar passo a passo

a lógica do sistema, examinando o conteúdo dos registradores e das áreas de memória
(PFLEEGER, 2004).

Os geradores de referência cruzada agem como um repositório dos requisitos do sistema e

também mantém links para outros documentos e com o código-fonte do sistema, relacionados
com cada requisito. Quando é proposta uma modificação em um requisito, podemos utilizar a
ferramenta para nos dizer quais outros requisitos, projetos e componentes serão afetados
(PFLEEGER, 2004).

Segundo Pfleeger (2004), os analisadores estáticos de código são responsáveis por calcular
informações estatísticas sobre atributos estruturais do código, tais como:

A profundidade do aninhamento;

Número de caminhos envolvidos;

Número ciclomático;

Número de linhas de código;

Comandos que nunca serão executados.

Por fim, os repositórios de gerência de configuração armazenam informações que controlam o

processo de alteração do projeto. Esses repositórios podem armazenar relatórios sobre
problemas e diversas informações relativas a cada problema e também sobre a organização,
podendo também disponibilizar marcadores sobre o status de cada problema (PFLEEGER, 2004).
TEMA 2 de 3

ʪ Material Complementar

Indicações para saber mais sobre os assuntos abordados nesta Unidade:

  Livros  

Engenharia de Software: Qualidade e Produtividade com

Tecnologia
HIRAMA, K. Engenharia de Software: qualidade e produtividade com tecnologia.  Rio de Janeiro:
Campus Elsevier. Capítulo 7.2 – Gerenciamento de Mudanças. 2011.

Processos de Desenvolvimento de Software

MASCHIETTO; R. et al. Processos de Desenvolvimento de Software. 1 ed. Capítulo 16.3 –
Problemas que podem ocorrer na manutenção de software. 2020.

Engenharia de Software: os Paradigmas Clássico e Orientado

a Objetos
SCHACH, S. R. Engenharia de Software: Os Paradigmas Clássico e Orientado a Objetos. 7. ed.
McGrawHill. Capítulo 15 – Manutenção de Pós Entrega. 2010.
Engenharia de Software: os Paradigmas Clássico e Orientado
a Objetos
SCHACH, S. R. Engenharia de Software: Os Paradigmas Clássico e Orientado a Objetos. 7. ed.
McGrawHill. Capítulo 9 – Planejamento e estimativas. 2010.
TEMA 3 de 3

ʪ Referências

MORAIS, I.; ZANIN, A. Engenharia de software. Porto Alegre: SAGAH, 2017.

MUNIZ, A. et al. Jornada Devops: unindo cultura ágil, Lean e tecnologia para entregar software
com qualidade.  2. ed. Rio de Janeiro: Brasport, 2020. (e-book)

PAULA FILHO, W. P. Engenharia de software: fundamentos, métodos e padrões. 3. ed. Rio de

Janeiro: LTC, 2009.

________. Engenharia de software: produtos. 4. ed. Rio de Janeiro: LTC, 2019. v. 1.

PFLEEGER, S. L. Engenharia de software: teoria e prática. 2. ed. São Paulo: Editora Pearson, 2004.

PINTO, A. S. A importância de criar uma cultura DevOps nas organizações. IETEC, 28/05/2018.
Disponível em: <https://www.ietec.com.br/clipping/2018/07-julho/A-import%C3%A2ncia-de-
criar-uma-cultura-DevOps-nas-organiza%C3%A7%C3%B5es.pdf>. Acesso em: 05/05/2021. 

PRESSMAN, R. S.; MAXIN, B. R. Engenharia de software: uma abordagem profissional. 8. ed.

Porto Alegre: Editora Bookman, 2016.

SBROCCO, J. H. T. D. C.; MACEDO, P. C. Metodologias ágeis: engenharia de software sob medida.

São Paulo: Érica, 2012.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Editora Pearson, 2019. 
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. Rio de Janeiro: Elsevier, 2013.