Metodologia de Gerenciamento de Projetos Ágil

PABLO MARQUESI
METODOLOGIA DE GERENCIAMENTO DE PROJETOS DE SOFTWARE DO
TRIBUNAL DE JUSTIÇA DO ESTADO DE MATO GROSSO BASEADO EM MÉTODOS
ÁGEIS
Trabalho apresentado ao curso MBA em
Gerenciamento de Projetos, Pós-Graduação lato
sensu, da Fundação Getulio Vargas como requisito
parcial para a obtenção do Grau de Especialista em
Gerenciamento de Projetos.
ORIENTADOR: Prof. André do Valle

Cuiabá - MT
Dezembro/ 2014
FUNDAÇÃO GETULIO VARGAS
PROGRAMA FGV MANAGEMENT
MBA EM GERENCIAMENTO DE PROJETOS
O Trabalho de Conclusão de Curso METODOLOGIA DE GERENCIAMENTO DE
PROJETOS DE SOFTWARE DO TRIBUNAL DE JUSTIÇA DO ESTADO DE MATO
GROSSO BASEADO EM MÉTODOS ÁGEIS, elaborado por Pablo Marquesi e aprovado pela
Coordenação Acadêmica do curso de MBA em Gerenciamento de Projetos, foi aceito como
requisito parcial para a obtenção do certificado do curso de pós-graduação, nível de especialização
do Programa FGV Management.
Cuiabá, 10 de dezembro de 2014
André Bittencourt do Valle
Coordenador Acadêmico Executivo
André Bittencourt do Valle
Professor Orientador

DECLARAÇÃO
A empresa ............................, representada neste documento pelo Sr.(a) ....................., (cargo)
............, autoriza a divulgação das informações e dados coletados em sua organização, na
elaboração do Trabalho de Conclusão de Curso intitulado (título) ..........., realizados pelo(s)
aluno(s) ......................., do curso de MBA em Gerência de Projetos, do Programa FGV
Management, com o objetivo de publicação e/ ou divulgação em veículos acadêmicos.
Local, Data
(assinatura)
(cargo)
(Empresa)

TERMO DE COMPROMISSO
O(s) aluno(s) Pablo Marquesi, abaixo assinado(s), do curso de MBA em Gerenciamento de
Projetos, Turma 06 do Programa FGV Management, realizado nas dependências da Unic no
período de 15/06/2012 a 31/01/2014, declara que o conteúdo do Trabalho de Conclusão de Curso,
METODOLOGIA DE GERENCIAMENTO DE PROJETOS DE SOFTWARE DO
TRIBUNAL DE JUSTIÇA DO ESTADO DE MATO GROSSO BASEADO EM MÉTODOS
ÁGEIS é autêntico, original e de sua autoria exclusiva.
Cuiabá, 10 de dezembro de 2014
Pablo Marquesi

RESUMO
Este trabalho apresenta a metodologia de gerenciamentos de projetos de software do criada
exclusivamente para o Departamento de Sistemas e Aplicações (DSA) do Tribunal de Justiça do
Estado de Mato Grosso.
O trabalho foi elaborado com o objetivo normatizar os processos de gerenciamento de projeto desde
sua concepção até sua entrega utilizando ferramentas e técnicas que dão apoio a métodos ágeis de
gerenciamento de projetos de software.
Palavras-chave: Métodos ágeis, ALM, metodologia, iterativo, incremental

ABSTRACT
This paper presents the methodology managements software projects created exclusively for the
Departamento de Sistemas e Aplicações (DSA) of the Tribunal de Justiça do Estado de Mato
grosso.
The work was done in order to standardize project management processes from conception to
delivery using tools and techniques that support agile software project management
Key words: Agile, ALM, methodology, iterative, incremental.

ÍNDICE
1 INTRODUÇÃO ..................................................................................................................12
1.1 Objetivo da metodologia ..................................................................................................12
1.2 Fundamentação teórica....................................................................................................12
1.3 Metodologia científica ......................................................................................................13
1.4 Público ...............................................................................................................................13
1.5 Como utilizar a MDS?......................................................................................................14
2 DESAMBIGUAÇÕES .......................................................................................................16
2.1 Metodologia x Framework...............................................................................................16
2.2 Projetos x Operações........................................................................................................16
2.3 Gerenciamento de Projetos Tradicional x Ágil..............................................................16
2.4 ALM x SDLC ....................................................................................................................17
3 MÉTODOS ÁGEIS PARA DESENVOLVIMENTO DE SOFTWARE.......................19
3.1 Manifesto para o desenvolvimento ágil de software......................................................19
3.2 Princípios por trás do Manifesto Ágil.............................................................................19
3.3 Principais métodos ágeis para desenvolvimento de software .......................................20
3.3.1 Scrum................................................................................................................................20
3.3.2 Extreme programming......................................................................................................21
3.3.3 Microsoft Framework Solutins.........................................................................................21
4 MODELO ITERATIVO E INCREMENTAL.................................................................23
5 APPLICATION LIFECYCLE MANAGEMENT (ALM) .............................................25
5.1 Pilares do ALM.................................................................................................................25
5.1.1 Pessoas..............................................................................................................................25
5.1.2 Processos ..........................................................................................................................27
5.1.3 Ferramentas ......................................................................................................................28
6 GRUPOS DE PROCESSOS MGPS-DSA........................................................................31

7 FASE DE DEFINIÇÃO .....................................................................................................33
7.1 Gerenciamento da demanda............................................................................................34
7.1.1 Gerenciamento da demanda: Entradas .............................................................................37
7.1.2 Gerenciamento da demanda: Atividades ..........................................................................37
7.1.3 Gerenciamento da demanda: Saídas.................................................................................39
7.2 Concepção da aplicação ...................................................................................................40
7.2.1 Concepção da aplicação: Entradas ...................................................................................43
7.2.2 Concepção da aplicação: Atividades ................................................................................43
7.2.3 Concepção da aplicação: Saídas.......................................................................................50
8 FASE DE CONSTRUÇÃO................................................................................................51
8.1 Desenvolvimento da aplicação.........................................................................................51
8.1.1 Desenvolvimento da aplicação: Entradas.........................................................................55
8.1.2 Desenvolvimento da aplicação: Atividades......................................................................55
8.1.3 Desenvolvimento da aplicação: Saídas ............................................................................92
9 FASE DE OPERAÇÃO .....................................................................................................93
9.1 Gerenciamento de incidentes...........................................................................................94
9.1.1 Gerenciamento de incidentes: Entradas............................................................................97
9.1.2 Gerenciamento de incidentes: Atividades ........................................................................97
9.1.3 Gerenciamento de incidentes: Saídas .............................................................................100
9.2 Gerenciamento de liberações.........................................................................................101
9.2.1 Gerenciamento de liberações: Entradas..........................................................................104
9.2.2 Gerenciamento de liberações: Atividades ......................................................................104
9.2.3 Gerenciamento de liberações: Saídas .............................................................................106
10 MONITORAMENTO E CONTROLE ..........................................................................107
10.1 Backlog Grooming..........................................................................................................107
10.2 Monitorar burdown chart .............................................................................................107
10.3 Controlar prazos de ofício e expedientes......................................................................108
10.4 Controlar capacidade da iteração .................................................................................108
10.5 Conduzir release planning.............................................................................................109

12 REFERÊNCIAS BIBLIOGRÁFICAS ...........................................................................111
13 GLOSSÁRIO ....................................................................................................................114

Sumário de figuras
Figura 1 – Manifesto ágil............................................................................................................... 19
Figura 2 – Como funciona o scrum ............................................................................................... 21
Figura 3 – Processo iterativo ......................................................................................................... 24
Figura 4 – Processo incremental.................................................................................................... 24
Figura 6 – Organograma do Departamento de Sistemas e Aplicações.......................................... 26
Figura 7 – Macrofluxo MGPS-DSA.............................................................................................. 32
Figura 8 – Diagrama do processo de Gerenciamento da demanda................................................ 35
Figura 9 – Diagrama do processo Concepção da aplicação .......................................................... 41
Figura 10 – Criando um novo projeto no visual Studio................................................................. 45
Figura 11 – Organização das branches na metodologia ................................................................ 45
Figura 12 – Fluxo de uma release.................................................................................................. 47
Figura 13 – Relação requisitos x work items................................................................................. 49
Figura 14 – Diagrama de do processo Desenvolvimento da aplicação ......................................... 53
Figura 15 – Cadastro de user story no team web access ............................................................... 56
Figura 16 – Formato dos detalhes de uma user story .................................................................... 57
Figura 17 – Diagrama do processo planejar iteração..................................................................... 59
Figura 18 – Diagrama Executar iteração ....................................................................................... 65
Figura 20 – Diagrama do processo Construção e testes unitários ................................................. 68
Figura 21 – Diagrama de status da user story................................................................................ 72
Figura 22 – Diagrama do processo Planejar testes ........................................................................ 74
Figura 23 – Transição de status dos bugs no MSF ........................................................................ 80
Figura 19 – Ciclo de vida das releases........................................................................................... 81
Figura 24 – Diagrama Executar testes de sistema ......................................................................... 82
Figura 25 – Diagrama Gestão do conhecimento............................................................................ 88
Figura 26 – Diagrama Gerenciamento de incidentes..................................................................... 95
Figura 27 – Diagrama Gerenciamento de liberações................................................................... 102
Figura 28 – Fluxo padrão para deploy em produção via release management............................ 104
Figura 29 – Gráfico burndown do Team Foundation Web Access ............................................. 108
Figura 30 – Velocidade do time no Team Foundation Web Access 2013 .................................. 109
Figura 31 – Artefatos utilizados no Microsoft Solutions Framework (MSF) ............................. 109

Lista de tabelas
Tabela 1 – Matriz de responsabilidade Gerenciamento da demanda ............................................ 36
Tabela 3 – Matriz de responsabilidade concepção da aplicação ................................................... 42
Tabela 4 – Matriz de responsabilidade planejar iteração............................................................... 59
Tabela 5 – Matriz de responsabilidade Executar iteração ............................................................. 65
Tabela 6 – Matriz de responsabilidade Construção e testes unitários ........................................... 69
Tabela 7 – Matriz de responsabilidade Planejar testes .................................................................. 75
Tabela 8 – Matriz de responsabilidade Executar testes de sistema ............................................... 83
Tabela 9 – Matriz de responsabilidade Gestão do conhecimento.................................................. 89
Tabela 10 – Matriz de responsabilidade Gerenciamento de incidentes......................................... 96
Tabela 11 – Matriz de responsabilidade Gerenciamento de liberações....................................... 103

12
1 INTRODUÇÃO
Desde o início da computação, surgiram diversas metodologias e modelos de maturidade todas com
o propósito direto ou indireto de garantir a entrega da aplicação dentro do tempo acordado, com os
recursos planejados e atendendo as funcionalidades esperadas, porém é importante ressaltar que
não há modelo ou metodologia perfeita, cada empresa deve procurar a que for mais adequada.
O Departamento de Sistemas e Aplicações (DSA), visando melhorar a qualidade de seus produtos,
estabeleceu uma Metodologia de Gerenciamento de Projetos de Software (MGPS) para ser usada
em todos os projetos do departamento. Esta metodologia foi escrita para atender as necessidades
de todas as equipes do DSA. Reconhece-se que esta metodologia deve ser escalável para poder
atender aos requisitos de projetos grandes e pequenos.
1.1 Objetivo da metodologia
O propósito deste documento é descrever todos os passos necessários para o desenvolvimento e
manutenção de produtos de software no DSA em todas as fases do ciclo de vida. Este documento
fornece um ponto de referência comum para falar e escrever sobre a prática de desenvolvimento
de sistemas no DSA.
Essa base comum se destina a aumentar a consciência e profissionalismo dos envolvidos
demonstrando papéis e responsabilidades durante o processo. Os papéis do Comitê Consultivo de
Mudança (CCM), Patrocinador, Gerente de Projetos, Time de desenvolvimento e outras partes
interessadas. Um entendimento comum sobre os requisitos e as razões subjacentes a esses
requisitos são fatores-chave para melhorar os resultados do projeto.
1.2 Fundamentação teórica
No último relatório do caos, ou CHAOS manifesto em inglês, desenvolvido pela (STANDISH
GROUP, 2013)1, apenas 39% dos projetos de TI são entregues dentro do prazo, custo e escopo. É
uma taxa relativamente baixa, porém já foi muito pior nos anos anteriores.
1 Instituto que realiza pesquisas sobre o desenvolvimento dos projetos de TI nas organizações.

13
De 2004 a 2012 a taxa de sucesso em projetos de TI cresceu aproximadamente 35% e a Standish
Group atribui este aumento á vários fatores, sendo um deles o aumento da adoção de métodos ágeis
no gerenciamento de projetos de TI.
O Departamento de Sistema e Aplicações (DSA) até então trabalhava seguindo um modelo
tradicional de gerenciamento de projetos de software e apesar de não medir a taxa de sucesso nos
projetos, era visível que na maioria dos casos os projetos não eram entregues com a qualidade
esperada.
Atualmente 29% dos projetos de desenvolvimento de software utilizam métodos ágeis (OSEIK,
2011). Baseando-se nessa visão e acompanhando uma tendência de mercado, o DSA decidiu adotar
estas práticas para projetos de software no sentido de aumentar a qualidade do produto entregue.
1.3 Metodologia científica
De acordo com o (MPS.BR, 2012) para se chegar em um nível de maturidade onde a gerência de
projeto é feita com base em um processo definido é necessário antes que este processo já esteja
sendo executado na organização. Portanto, antes da Metodologia de Gerenciamento de Projetos de
Software (MGPS) do Tribunal de Justiça de Mato Grosso começar a ser escrita vários projetos
foram experimentados utilizando abordagem dos métodos ágeis.
Seguindo o método de pesquisa empírica diversos experimentos foram realizados no decorrer de
18 meses, onde ferramentas, processos e técnicas foram implementadas de forma gradual dentro
do departamento de sistemas e aplicações do Tribunal de Justiça do Estado de Mato Grosso. Cada
item pesquisado era implementado, testado, amadurecido e validado em reuniões de
acompanhamento e se não fosse bem aceito, este item era modificado ou até mesmo retirado do
ciclo de vida do projeto de software.
Este trabalho não teve como foco a exposição dos resultados em números, sendo utilizada uma
metodolgogia de pesquisa qualitativa, onde o principal indicador de progresso do sucesso das
práticas adotadas era reuniões de feed back e a aceitação das práticas durante o tempo.
1.4 Público
A Metodologia de Gerenciamento de Projetos de Software (MGPS) foi criada para ser utilizada
por todos os colaboradores do Departamento de Sistemas e Aplicações (DSA), e a equipe de

14
tecnologia do Departamento de Aprimoramento da Primeira Instância (DAPI). O DSA é formado
por quatro equipes: Equipe de Qualidade de Software, Equipe Administrativa, Equipe Judiciária e
Equipe de Recursos Humanos, todas devem utilizar a metodologia como corpo de conhecimento
para auxilio nas rotinas diárias.
1.5 Como utilizar a MDS?
A Metodologia de Gerenciamento de Projetos de Software (MGPS) está dividida em duas partes:
Conceitualização e Metodologia e Processo.
A primeira parte introduz o leitor à vários conceitos utilizados na metodologia, aborda várias
disciplinas utilizadas no gerenciamento de projetos de software, construção e melhoria do processo.
Tem o objetivo de promover o alinhamento do conhecimento das partes interessadas sobre as
práticas que serão utilizadas durante todo o ciclo de vida do software.
A segunda parte descreve a metodologia em si, está organizada de forma a demonstrar suas fases,
processos e atividades. São no total 3 fases: definição, construção e operação. Cada processo possui
um diagrama (representação básica do processo focada nas principais atividades), uma Matriz de
Responsabilidade (RACI)2, entradas dos processos, atividades a serem executadas e saídas.
2 RACI é uma ferramenta utilizada para atribuição de responsabilidades,dentro de um determinado processo,projeto,
serviço ou mesmo no contexto de um departamento / função (PALMA, 2013). R: Responsável por executar uma
atividade (o executor); A: Autoridade, quem deve responderpela atividade, o dono (apenas uma autoridade pode ser
atribuída por atividade); C: Consultado, quem deve ser consultado e participar da decisão ou atividade no momento
que for executada; I: Informado, quem deve receber a informação de que uma atividade foi executada.

15
Parte I - Conceitualização

16
2 DESAMBIGUAÇÕES
2.1 Metodologia x Framework
De acordo com (PMI, 2008) um framework de gerenciamento de projetos é um conjunto de
conhecimentos amplamente reconhecido como boa prática. Tais práticas são aplicáveis à maioria
dos projetos e na maior parte do tempo em sua e que existe um consenso geral de que a aplicação
correta dessas habilidades, ferramentas e técnicas pode aumentar as chances de sucesso em uma
ampla gama de projetos. Uma boa prática não significa que o conhecimento descrito deva ser
sempre aplicado uniformemente em todos os casos, a organização e/ou a equipe de gerenciamento
do projeto é responsável por determinar o que é apropriado para um projeto específico.
Uma metodologia além de dizer “o que fazer” deve dizer “como fazer”, isso significa que, todas
atividades devem ser seguidas para que se obtenha êxito. Uma metodologia também reúne boas
práticas, porém devem ser seguidas de forma prescritiva e organizada. Segundo (MAIA, 2011) uma
metodologia é um conjunto de métodos e técnicas aplicadas para um determinado fim. É o caminho
percorrido, a maneira utilizada para atingir o objetivo, em outras palavras, em uma metodologia
todos os processos são conhecidos e previamente definidos.
2.2 Projetos x Operações
O conceito mais difundido sobre o que é um projeto vem do (PMI, 2008), que diz que é um esforço
temporário empreendido para se criar um produto, serviço ou resultado exclusivo. Ao contrário de
projetos, conforme explica (RODRIGUES, CAMPOS, et al., 2011), operações, também chamadas
de rotinas, são funções organizacionais que realizam a execução contínua de atividades que
produzem o mesmo produto ou fornecem um serviço repetitivo. As operações são esforços
permanentes que geram saídas repetitivas, com recursos designados a realizar basicamente o
mesmo conjunto de atividades, de acordo com os padrões institucionalizados no ciclo de vida de
um produto ou serviço.
2.3 Gerenciamento de Projetos Tradicional x Ágil
Gerenciamento de um projeto é a aplicação de conhecimentos, habilidades, ferramentas e técnicas
às atividades do projeto a fim de atender aos seus requisitos. Projetos serão sempre projetos

17
independentemente da forma como são gerenciados, porém projetos diferentes precisam de
métodos diferentes.
Em geral gerenciamento ágil de projetos são mais adaptáveis à projetos de escopo aberto, tais
como: desenvolvimento de software, melhoria continua de produto e projetos de escopo indefinido.
Já gerenciamento de projetos tradicionais são melhores aceitos em construções civis, infraestrutura
de TI, móveis sob medida, etc.
De acordo com (BUILDER, 2013) em métodos tradicionais de gerenciamento entende-se que o
produto só faz sentido quando é entregue em sua totalidade, ou seja, apenas com 100% do projeto
cumprido é que o cliente irá perceber algum valor. Por outro lado, métodos ágeis devem ser usados
em projetos que permitem que um conjunto mínimo de funcionalidades já servirá para entregar
valor e também quando existe grande incerteza sobre a solução que o cliente busca.
Outro ponto importante entre os dois métodos é que, em métodos ágeis, combinado que o projeto
irá entregar as funcionalidades mínimas o cliente nem sempre tem noção do custo total do produto.
Em métodos tradicionais o valor é fechado junto com o escopo e cumprir esse escopo acaba sendo
responsabilidade apenas da empresa
Práticas ágeis não são apropriadas para todos os cenários. Em especial, a agilidade é melhor
aproveitada nas seguintes situações: Projetos cujo esforço é intelectual; escopo altamente sujeito a
mudanças; restrições agressivas de tempo.
2.4 ALM x SDLC
É muito comum a comparação entre o Gerenciamento do Ciclo de Vida da Aplicação, do inglês
Application Lifecycle Management (ALM) e o Ciclo de Vida de Desenvolvimento de Sistemas
(CVDS), do inglês Systems Development Life Cycle (SDLC).
O SDLC está ligado com o desenvolvimento de um aplicativo de software, incluindo requisitos,
arquitetura, codificação, testes e gerenciamento de configurações. Já o ALM se preocupa com o
processo de ponta-a-ponta, pois este envolve todo o tempo em que a organização está investido
recursos com esse ativo, desde a sua ideia inicial até o fim da vida do aplicativo.
“Até há pouco tempo atrás falávamos de SDLC ao invés de ALM. Daí dá para perceber
que nos preocupávamos apenas como ciclo de vida de desenvolvimento da aplicação e,

18
por isso, focamos mais nas ferramentas usadas pelos times de desenvolvimento.”
(ABADE, 2014).

19
3 MÉTODOS ÁGEIS PARA GERENCIAMENTO DE PROJETOS DE SOFTWARE
O termo “Metodologias Ágeis” tornou-se popular em 2001 quando dezessete especialistas em
processos de desenvolvimento de software representando os métodos Scrum, Extreme
Programming (XP) e outros, estabeleceram princípios comuns compartilhados por todos esses
métodos (SOARES, 2013). Foi então criada a Aliança Ágil e o estabelecimento do “Manifesto
Ágil”.
O manifesto ágil é um documento, que declarou uma nova forma de entender projetos que lidam
diariamente com imprecisão e imprevisibilidade, características inerentes ao processo de
desenvolvimento de software e tecnologia (AUDY, 2013). Os métodos envolvidos no Manifesto
criaram uma nova filosofia para gerenciamento de projetos de software, que passaram a ser
chamados de "Métodos Ágeis".
3.1 Manifesto para o desenvolvimento ágil de software
Figura 1 – Manifesto ágil
3.2 Princípios por trás do Manifesto Ágil
1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de
software com valor agregado.
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
3. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o
cliente.

20
4. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com
preferência à menor escala de tempo.
5. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo
o projeto.
6. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte
necessário e confie neles para fazer o trabalho.
7. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de
desenvolvimento é através de conversa face a face.
8. Software funcionando é a medida primária de progresso.
9. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores,
desenvolvedores e usuários devem ser capazes de manter um ritmo constante
indefinidamente.
10. Contínua atenção à excelência técnica e bom design aumenta a agilidade.
11. Simplicidade -a arte de maximizar a quantidade de trabalho não realizado--é essencial.
12. As melhores arquiteturas, requisitos e designs emergem de equipes auto organizáveis.
13. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e
ajusta seu comportamento de acordo.
3.3 Principais métodos ágeis para desenvolvimento de software
Existem diversas disciplinas no mercado para auxiliar no gerenciamento de projetos ágeis de
desenvolvimento de software e todas se baseiam na filosofia e nos princípios do manifesto ágil que
foi citado logo acima. A Metodologia de Gerenciamento de Projetos de Software (MGPS) utiliza
diversas téncicas dos métodos ágeis citados abaixo:
3.3.1 SCRUM
Scrum é um processo de gerenciamento de projetos ágeis, adaptado para a área de desenvolvimento
de software, pelo especialista Ken Schwaber (JUNIOR e RAHAL, 2012). Ken define Scrum, em
um de seus livros, como: “um processo Ágil ou ainda um framework para gerenciamento de
projetos Ágeis. É um processo de gerência de projetos, certamente não é uma metodologia, pois
isto seria pesado demais”.

21
Figura 2 – Como funciona o scrum
Fonte: http://www.brq.com/metodologias-ageis/
3.3.2 EXTREME PROGRAMMING
Programação extrema (do inglês eXtremeProgramming), ou simplesmente XP, é uma metodologia
ágil para equipes pequenas e médias e que irão desenvolver o software com requisitos vagos e em
constante mudança. Para isso, adota a estratégia de constante acompanhamento e realização de
vários pequenos ajustes durante o desenvolvimento de software (WIKIPEDIA, 2014).
3.3.3 MICROSOFT FRAMEWORK SOLUTINS
O Microsoft Solutions Framework (MSF) tem sido usado pela Microsoft como o seu "método" para
desenvolvimento de soluções de software dentro da Microsoft e também para os milhares de
clientes e parceiros da Microsoft em todo o mundo. A disseminação deste método, agora na versão
4.0 no Visual Studio 2005, normalmente induz as pessoas a compará-lo com outros "métodos" da
indústria, como o RUP ou XP, entre outros. É importante entender, entretanto, o que são estes
elementos antes de compará-los.
Assim como em outros frameworks de desenvolvimento ágil, um projeto MSF é regido por ciclos
ou iterações. A cada ciclo, cada componente da equipe executa suas funções e atualiza o resultado

22
do seu trabalho conforme a necessidade. Os ciclos se repetem até que o projeto seja concluído ou
cada versão seja lançada.
A Microsoft não classifica o MSF como uma metodologia, mas sim como um framework.
Basicamente que o MSF serve como um guia e uma coleção de boas práticas.

23
4 MODELO ITERATIVO E INCREMENTAL
Em projetos muito complexos, como é o caso do projeto de software, o cliente pode não estar apto
a definir os requisitos logo no início ou pode não ter certeza de como quer o produto final. O
modelo iterativo e incremental é mais flexível em garantir que qualquer requisição de mudança
feita pelo cliente possa ser incluída como parte do projeto.
O processo de desenvolvimento iterativo e incremental é dividido em iterações, onde ao final de
cada uma delas é gerado um incremento do software que é um avanço na conclusão do produto. As
iterações são pequenos projetos onde existem etapas de fluxos de trabalho como captura dos
requisitos, análise dos requisitos, projeto, implementação e teste.
O uso do desenvolvimento iterativo faz-se necessário durante o desenvolvimento devido a algumas
razões, como:
 Melhor gerenciamento da evolução do sistema desenvolvido: melhor adaptação a mudanças
nos requisitos;
 Redução do risco de entendimento dos requisitos: Cliente vê resultado mais cedo e pode
dar retorno a tempo de fazer pequenos ajustes sem grandes impactos no planejamento do
projeto;
 Aumenta confiabilidade do sistema desenvolvido;
 Aceleração do tempo de desenvolvimento: desenvolvedores buscam resultados de escopo
pequeno e claro e a capacidade de reutilização aumenta.
De acordo com (WIKIPEDIA, 2013) o desenvolvimento iterativo é uma estratégia de retrabalho
em que o tempo de revisão e melhorias de partes é pré-definido. Começa com uma implementação
simples de um pequeno conjunto de requisitos de software e de forma iterativa aumenta as versões
evoluindo até que o sistema completo seja implementado e pronto para ser implantado, conforme
pode ser visto na Figura 3 – Processo iterativo.
Ainda de acordo com (WIKIPEDIA, 2013) o desenvolvimento incremental é uma estratégia de
planejamento estagiado em que várias partes do sistema são desenvolvidas em paralelo, e
integradas quando completas o contrário desta abordagem é desenvolver todo o sistema com uma
integração única. Veja o exemplo na Figura 4 – Processo incremental.

24
Figura 3 – Processo iterativo
Figura 4 – Processo incremental

25
5 APPLICATION LIFECYCLE MANAGEMENT (ALM)
ALM descreve métodos para gerenciar o desenvolvimento de software e iniciativas de TI
automatizando processos de ponta-a-ponta e integrando a informação de várias formas. Integração
fornece consistência, previsão e também introduz oportunidades de automação.
De acordo com (GARCIA, 2011), o ALM é a união entre gerência de negócio com engenharia de
software, suportada por ferramentas que facilitam e integram processos como análise de requisitos,
modelagem de arquitetura, desenvolvimento de código, gerenciamento de mudanças,
gerenciamento de testes e gerenciamento de versões de produtos realizados.
ALM é todo o processo que norteia toda a vida útil de uma aplicação desde a sua concepção,
passando pela construção, operação e evolução. Nãoobserva apenas qual é o método de construção,
mas preocupa também na governaça da instituição (CONDÉ, 2009).
O ALM tem seu foco na produtividade dos recursos alocados, bem como auditar suas tarefas e
ações durante o projeto. Essa gestão aliada ao processo de melhores práticas escolhido, como os
métodos ágeis, seja ele qual for (CMMI, RUP, MSF, PMI, SCRUM, XP ou qualquer outro),
possibilita gerar padrões de avaliação. Pilares do ALM
5.1 Pilares do ALM
O ALM é estruturado com base em três pilares que se complementam, são eles: pessoas, processos
e ferramentas. Quando unidos, fornecem os recursos necessários para que as empresas possam
gerenciar o ciclo de vida das suas aplicações (CONDÉ, 2009).
5.1.1 PESSOAS
De acordo com (CONDÉ, 2009) a participação de pessoas é o pilar mais importante da tríade.
Pessoas bem treinadas e capacitadas formam a cola que une adequadamente as ferramentas e os
processos do ALM. Cada uma destas pessoas possui seus objetivos, segue abaixo os principais
papeis dentro deste pilar:

26
5.1.1.1 Estrutura organizacional do DSA
O Departamento de sistemas e aplicações utiliza uma estrutura organizacional clássica, mostrada
na Figura 5 – Organograma do Departamento de Sistemas e Aplicações, onde cada colaborador
possui um superior bem definido.
Figura 5 – Organograma do Departamento de Sistemas e Aplicações
Analista de Testes: O objetivo do Analista de Testes é desenhar as fundações do teste. Inclui
estruturar tanto do ponto de vista lógico, como físico de como o testes funcionarão, bem como o
seu comportamento nos ambientes.
Apesar do analista de teste estar lotado dentro de uma equipe de sistemas, ele está subordinado
ao gerente de qualidade, conforme visto na Figura 5 – Organograma do Departamento de
Sistemas e Aplicações.
Arquiteto: O objetivo do Arquiteto é desenhar as fundações da aplicação. Inclui estruturar tanto
do ponto de vista lógico, como físico de como a aplicação funcionará, bem como o seu
comportamento no ambiente de produção. Em paralelo, o Arquiteto procura reduzir a
Diretor
Gerente de
sistemas
Arquiteto de
sistemas
Analista de
sistemas
Desenvolvedor
Controller
Gerente de
Qualidade
Analista de
qualidade
Técnico de
qualidade
Controller

27
complexidade da aplicação, dividindo-a em partes simples. O uso de boas práticas e modelos de
mercado ajuda o Arquiteto na execução do seu trabalho.
Controller de projetos: O controlador de projetos deverá manter relatório consolidado das
atividades delegadas por meio do sistema de Gestão de Atendimento, das Ordens de Serviço e dos
bilhetes de atividades inseridos nas ferramentas de desenvolvimento, com os respectivos prazos
estabelecidos.
Desenvolvedor: O objetivo do desenvolvedor é transformar as especificações em código. O
desenvolvedor também ajuda na criação da especificação física de algumas funcionalidades,
estimar tempo para a construção, compilar e preparar a aplicação para a distribuição.
Diretor do departamento: O diretor do departamento controla a execução dos projetos
estratégicos e operacionais de todo o departamento. Atua na fiscalização dos contratos para
assegurar o seu correto cumprimento. Fornece parecer aos documentos enviados ao departamento.
Gerente de sistemas: O objetivo do Gerente do Projeto é entregar o projeto dentro do orçamento
e prazo acordados. Seu trabalho se concentra no planejamento do projeto, elaboração do
cronograma, monitoração das atividades do projeto.
Gerente de qualidade: No ciclo de vida de desenvolvimento de software, o gerente de qualidade
responde pelas ações de controle de qualidade dos produtos, ou seja, se estes foram desenvolvidos
de acordo com as especificações acordadas e se atendem às expectativas dos clientes (BASTOS,
RIOS, et al., 2007).
Técnico de qualidade: O objetivo do técnico de qualidade é descobrir problemas na aplicação e
informá-los para a correção. O trabalho do Testador consiste em executar testes pré-definidos ou
exploratórios, coletar as amostras dos resultados e compará-las com o esperado. Uma vez detectado
um problema, o Testador deve informar à equipe as condições para reprodução do problema.
5.1.2 PROCESSOS
O pilar “processos” é identificado como todo o conjunto de boas práticas, artefatos, guias e manuais
que conduzem a construção e manutenção de uma aplicação.

28
Entenda que ao falarmos de processos, estamos falando desde os processos de levantamento das
necessidades.
5.1.3 FERRAMENTAS
As “ferramentas” são os meios/equipamentos/tecnologias que automatizam e facilitam a condução
dos processos pelas pessoas. Existem no mercado diversas ferramentas que suportam o ciclo de
vida de aplicações baseada em de ALM, segue abaixo uma lista das que são utilizadas na
Metodologia de Gerenciamento de Projetos de Software (MGPS) do DSA:
Microsoft Team Foundation Server: O Team Foundation Server (TFS) é a plataforma de
colaboração na essência da solução de gerenciamento do ciclo de vida de aplicativos (ALM) da
Microsoft. O TFS oferece suporte para práticas de desenvolvimento ágeis, para vários IDE’s e
plataformas localmente ou na nuvem e fornece as ferramentas necessárias para gerenciar com
eficiência projetos de desenvolvimento de software em todo o ciclo de vida de TI.
Microsoft Visual Studio: O Visual Studio é um pacote de ferramentas de desenvolvimento de
software baseadas em componentes e outras tecnologias para a criação de aplicativos avançados
de alto desempenho. Além disso, o Visual Studio é otimizado para projeto, desenvolvimento e
implantação em equipe usando Visual Studio Online ou Team Foundation Server.
Microsoft Test Manager: Utilizado para testar os aplicativos desenvolvidos. O MTM armazena
planos e resultados de teste no Team Foundation Server (TFS).
Microsoft Sharepoint Server: A integração entre Visual Studio Team Foundation Server e
Produtos do SharePoint fornece a administradores, líderes de projeto e colaboradores do projeto
com o compartilhamento eficiente de dados de conhecimento e ferramentas organizacionais. Essa
integração inclui a opção para criar um site, conhecido como um team project portal, para cada
projeto de equipe. As equipes podem usar este portal para compartilhar a orientação do processo,
os documentos de projeto, modelos e relatórios de acordo com a função de cada membro da equipe
do projeto. É possível usar qualquer versão suportada do Produtos do SharePoint com Team
Foundation Server.
Microsoft Project Server: É uma solução online flexível para o gerenciamento de portfólio de
projetos (PPM) e para o trabalho diário. Permite priorizar investimentos em portfólio de projetos e
produzir o valor de negócios pretendido de praticamente qualquer lugar.

29
Microsoft Release Management: Com o Microsoft Release Management é possível configurar,
aprovar e implantar os aplicativos para qualquer ambiente e de forma automatizada, não importa o
quão complexa é a configuração. O software permite criar um fluxo padrão de subida de verão com
rastreabilidade e qualidade.
Microsoft SystemCenter Operation Manager: A sincronização entre o operations manager e o
team foundation server (TFS) possibilita uma comunicação eficiente entre os desenvolvedores e as
operações de tecnologia da informação (TI). A integridade do ambiente do TFS é essencial para
todos os processos de desenvolvimento. Conforme o ambiente utilizado, é possível importar
pacotes de gerenciamento e monitoramento do TFS que ofereçam visibilidade em tempo real da
integridade do ambiente de desenvolvedor do TFS.
Microsoft System Center Virtual Machine Manager (SCVMM): O Virtual Machine Manager
(VMM) é uma solução de gerenciamento para o datacenter virtualizado, permitindo configurar e
gerenciar o host de virtualização, as redes e os recursos de armazenamento para criar e implantar
máquinas virtuais e serviços nas nuvens privadas criadas.

30
Parte II – Metodologia e processo

31
6 GRUPOS DE PROCESSOS MGPS-DSA
A Metodologia de Gerenciamento de Projetos de Software (MGPS) é composta por três fases e seis
principais processos conforme pode ser visualizado na Figura 6 – Macrofluxo.
Tudo se inicia sempre que houver algo a ser feito, desde um pedido de melhoria em um sistema à
um projeto de novo de sistema. O processo de Gerenciamento da demanda a demanda é responsável
por fazer a triagem da demanda e direcionar para os outros processos.
O processo de monitoramento e controle suporta todos os outros processos no sentido de fornecer
atividades necessárias para acompanhar, analisar e organizar o progresso e o desempenho do
projeto.
Figura 6 – Macrofluxo MGPS-DSA

33
7 FASE DE DEFINIÇÃO
O objetivo desta fase é garantir que a aplicação esteja sempre aderente as necessidades do negócio.
Esta fase também é responsável por estruturar a ideia, definir estratégias, métodos e ferramentas
para guiar a manutenção do produto ou o surgimento. Esta fase é composta pelos seguintes
processos e subprocessos:
1.1. Gerenciamento da demanda
1.2. Concepção da aplicação

34
7.1 Gerenciamento da demanda
Este processo tem por objetivo receber todas as demandas originadas pelas áreas de negócio e dar
um tratamento inicial, sejam elas: um projeto, uma manutenção evolutiva ou uma manutenção
corretiva. Para cada tipo de demanda existirá um tratamento específico.
Ao executar as atividades do processo de forma eficiente, amplia-se a colaboração entre a área de
TI e os clientes.
O Gerenciamento de demanda trata-se de um processo contínuo que realiza o encadeamento das
demandas com os serviços e projetos de TI.

35
Figura 7 – Diagrama do processo de Gerenciamento da demanda

36
Tabela 1 – Matriz de responsabilidade Gerenciamento da demanda
Atividades do processo Gestão da demanda
Coordenador
AssessoriadaCTI
DiretordoDSA
AssessoraDSA
Gerentedesistemas
Controller
Arquitetodesistemas
Analistadesistemas
Desenvolvedor
Gerentedequalidade
Analistadequalidade
Técnicodequalidade
Cliente
Realizar triagem da demanda R R/A R
Analisar alinhamento ao PDTI/PTI/PE R/A
Estimar data do projeto R/A C
Comunicar partes interessadas R
Responder solicitação R
Definir chamado em cronograma C R

37
7.1.1 GERENCIAMENTO DA DEMANDA: ENTRADAS
 Processo/Expediente: Documentos oficiais do poder judiciário, físicos controlados por
sistema eletrônicos.
 Chamado: Um chamado é um pedido de um cliente registrado em um sistema de
gerenciamento de chamados. Normalmente possui um número único, e um prazo de
atendimento.
 E-mail: Pedido encaminhado pelo cliente via e-mail para a assessoria do DSA ou gerentes
de equipe;
 ATA de reunião: Documento formal que registra as solicitações de clientes durante uma
reunião.
7.1.2 GERENCIAMENTO DA DEMANDA: ATIVIDADES
7.1.2.1 Realizar triagem da demanda
Identificar qual a classificação da demanda e definir para onde deve ser encaminhada. As demandas
são classificadas da seguinte forma:
 Novo Projeto: Demanda classificada como Novo projeto deve ser direcionada para a
atividade “Analisar alinhamento ao PDTI/PETIC/PE.”
 Manutenção corretiva: Demanda classificada como corretiva deve ser direcionada para o
Processo Gerenciamento de incidentes.
 Manutenção evolutiva Demanda classificada como evolutiva, deve ser verificada qual a
forma de entrada:
 Artefato de entrada:
 Se o artefato de entrada for um oficio, a demanda deve ser direcionada para o
“Processo Gerenciamento do desenvolvimento da aplicação”
 Se o artefato de entrada for um “chamado”, o mesmo deverá ser analisado e inserido
em cronograma e direcionado ao “Processo Gerenciamento do desenvolvimento da
aplicação”

38
7.1.2.2 Analisar alinhamento ao PDTI/PETIC/PE
Essa atividade tem como objetivo alinhar se as solicitações para desenvolvimento de novos projetos
estão de acordo com o Planejamento estratégico desse Tribunal, Planejamento estratégico da TI e
do Plano diretor de TI da CTI.
Analise de viabilidade estratégica é responsável por alinhar os projetos solicitados com a estratégia
do Poder Judiciário de Mato Grosso e da CTI, o escritório de projeto utiliza a viabilidade estratégica
para programar as prioridades de execução dos projetos, bem como planejar a execução dos
projetos aprovados parcialmente na viabilidade técnica. Os projetos que necessitarem de aquisições
para sua execução será solicitado ao Diretor do Departamento a elaboração do termo de referência.
Quando a solicitação estiver alinhada ao PDTI/PETIC/PE deve ser executado o sub processo
Estimar data do projeto.
7.1.2.3 Estimar data do projeto
Este subprocesso tem como principal objetivo organizar os prazos das solicitações enviadas via
expediente ou processo para o Departamento de Sistemas e Aplicações.
Quando um ofício é enviado para alguma equipe de sistema as informações técnicas deverão ser
encaminhadas ao gabinete da diretoria em prazo hábil para a confecção da resposta.
Para as solicitações de novos projetos em que as informações fornecidas na solicitação não são
suficientes para estimar escopo inicial e prazos, é necessário solicitar ao cliente informações mais
detalhadas para que seja possível o andamento do projeto. Essas informações devem ser registradas
no documento “Formulário de pedido de novo sistema” disponível no portal do departamento de
sistemas e aplicações.
Quando esse prazo é suficiente para a resposta deve ser agendada a execução da solicitação no
cronograma, ou seja, deverá se dada uma data prevista de execução da solicitaçãop acordo com os
projetos em andamento e suas respectivas prioridades.
Quando a solicitação já vem com prazo pré-definido para a resposta e o mesmo não for suficiente
deve ser solicitada uma dilação de prazo. A dilaçãp de prazo é um pedido formal via e-mail
solicitando ao Coordenador de TI mais tempo para dar uma previsão de execução da solicitação,
para análise necessária e definição de prazo para execução do novo projeto.

39
7.1.2.4 Responder solicitação
Caso a solicitação não esteja alinhada ao PDTI/PETIC/PE uma resposta fundamentada deve ser
enviada ao solicitante sobre os motivos do indeferimento e o processo Gerenciamento de Demanda
deve ser finalizado.
7.1.2.5 Comunicar partes interessadas
Comunicar aos gestores, gerentes e colaboradores envolvidos no projeto as datas estimadas para
execução do mesmo, e as prioridades considerando os projetos em andamento.
7.1.3 GERENCIAMENTO DA DEMANDA: SAÍDAS
 Despcho em ofício
 Data prevista para analisar a solicitação

40
Concepção da aplicaçãoConcepção da aplicação contempla atividades necessárias à concordância
das partes interessadas com os objetivos, escopo, arquitetura e o planejamento do projeto. Ainda
neste processo todas as ferramentas da plataforma ALM são configuradas para suportar o novo
projeto. Os requisitos iniciais são levantados e registrados no Team Foundation Server (epics).

41
Figura 8 – Diagrama do processo Concepção da aplicação

42
Tabela 2 – Matriz de responsabilidade concepção da aplicação
Atividades do processo Gerenciamento da
demanda
Coordenador
AssessoriadaCTI
DiretordoDSA
AssessoraDSA
Gerentedesistemas
Controller
Arquitetodesistemas
Analistadesistemas
Desenvolvedor
Gerentedequalidade
Analistadequalidade
Técnicodequalidade
Cliente
Elaborar (TAP) Termo de Abertura do Projeto A/R C
Elaborar LTI R A/R C
Alocar Recursos C
Configurar Plataforma ALM A/R
Documentar requisitos de Negócio(Epics) A/R I
Elaborar Plano de entregas (release) A/R

43
7.1.4 CONCEPÇÃO DA APLICAÇÃO: ENTRADAS
 Formulário de pedido de novo sistema: Este documento foi criado para que o cliente
forneça o mínimo de informações necessárias para se iniciar a elaboração do termo de
abertura do projeto.
7.1.5 CONCEPÇÃO DA APLICAÇÃO: ATIVIDADES
7.1.5.1 Elaborar TAP
Elaborar o TAP (termo de abertura do projeto) é a atividade de desenvolvimento de um documento
que formalmente autoriza um projeto ou uma fase do projeto e a documentação dos requisitos
iniciais que satisfaçam as necessidades e expectativas das partes interessadas (PMI, 2008).
7.1.5.2 Elaborar LTI
O levantamento técnico inicial é um dos artefatos da análise estruturada para projetos de sistemas
de informação. Ele facilita uma análise preambular deste, sendo de grande relevância durante as
primeiras fases, permitindo a captura de todas as perspectivas que o sistema pode abranger
(WIKIPEDIA, 2013). Serva como ferramenta de auxílio, a evitar alguns dos problemas mais
custosos com que as pessoas envolvidas no projeto poderão ter que se confrontar.
Este documento descreve as perspectivas que o projeto pode abranger, como: Objetivos, Escopo,
Referencia, Benefícios, descrição dos Usuários, Visão geral do Produto, características funcionais
e não funcionais.
7.1.5.3 Alocar recursos
Alocação de recursos é o uma atividade pela qual recursos existentes são distribuídos entre usos
alternativos, que podem ser finais (programas ou atividades-fim), intermediários (os diversos
insumos e atividades necessários à produção do serviço final), ou definidos em termos dos usuários
dos serviços.

44
7.1.5.4 Configurar plataforma ALM
Essa atividade consiste em configurar as ferramentas da Plataforma ALM. A plataforma ALM
consiste de várias ferramentas com objetivos específicos para cada segmento no ciclo de vida da
aplicação.
7.1.5.4.1 Configurando o Project Server
Os projetos deverão ser gerenciados por meio da ferramenta Microsoft Project Server, para isso
deverá ser criado os projetos de acordo com o portfólio da Coordenadoria de Tecnologia da
Informação.
Após a criação do projeto no TFS, este deverá ser sincronizado com o projeto no Microsoft Project
Server de modo que as alterações feitas no TFS reflitam nos projetos no Project Server, para isso
utilize a aba “Team” e escolha “Choose Team Project” para poder criar e/ou exibir itens do TFS.
7.1.5.4.2 Configurando o TFS
Para que a equipe do DSA possa começar a trabalhar, é necessário criar o Team Project no TFS
para estabelecer um repositório de código-fonte e um lugar para as equipes planejar, acompanhar
e colaborar com o ciclo de vida da aplicação.
Para isso utilize a ferramenta Microsoft Visual Studio e por meio da opção New Team Project
Wizard crie o Team Project, conforme pode ser visto na Figura 9 – Criando um novo projeto. Em
seguida escolha a última versão do MSF for Agile Software Development – TJMT3 e em seguida
escolha qual será o gerenciador de controle de versões podendo ser o TFS ou GIT.
3 Microsoft Solution Framework personalizad para a metodologia do DSA.

45
Figura 9 – Criando um novo projeto no visual Studio
Fonte: http://msdn.microsoft.com/en-us/library/ms181477.aspx
Quando terminar, é possível ver o Team Project no Team Explorer. Também é possível escolher o
Acesso Web link para se conectar ao seu Team project usando o Team Web Access.
7.1.5.4.3 Configuração das branches
É necessário também a criação da estrutura básica dos arquivos e Branches que está definida no
Documento “Padrões de Desenvolvimento” do DSA e ilustrada na Figura 10 – Organização das
branches na metodologia.
Figura 10 – Organização das branches na metodologia
Fonte: Adaptado http://vsarbranchingguide.codeplex.com/
Após a criação do projeto, devem ser adicionado os grupos da equipe do Active Directory em cada
grupo padrão do TFS. Ex.: Adicionar o grupo do AD “ALM_Gerentes_Qualidade” no grupo do

46
TFS “Project Administrator”. As informações de grupos e permissões pode ser visualizado no
documento de Permissões do ALM.
7.1.5.4.4 Visual Studio ou Eclipse
Para configurar o restante das ferramentas, é necessário a criação da arquitetura básica do sistema.
Esta arquitetura deve possuir o arquivo de configuração (.proj) dos projetos que serão publicdados
(este arquivo normalmente é criado pelas IDEs Visual Studio (.csproj) ou Eclipse(.proj).
O Arquiteto da equipe deve criar a arquitetura do sistema e então realizar o primeiro check-in dos
arquivos para o TFS. Com isso, será possível a criação das Builds dos projetos publicáveis.
Deve-se então vincular as políticas de check in “Work Items” e “Changeset Comments Policy” no
projeto criado para que a equipe sempre informe e vincule as tarefas a suas mudanças de código.
7.1.5.4.5 Team Foundation Server – Builds
A Build do projeto é o processo de se gerar os arquivos de uma versão do sistema a partir do código
fonte. Esses arquivos podem conter scripts de banco de dados, imagens, binários, etc.
O Arquiteto da equipe deve criar as builds de cada projeto seguindo as configurações definidas no
Documento “Padrões de Desenvolvimento” do DSA. Neste processo, um administrador do ALM
pode acompanhar para colaborar com sua configuração.
O projeto deve possuir pelo menos 4 Builds que são referentes a cada ambiente disponibilizado
para a plataforma ALM. São elas: Alpha (ambiente de desenvolvimento), Beta (ambiente de teste),
RC (ambiente de homologação) e Stable (ambiente de produção).
7.1.5.4.6 Release Management
A ferramenta Release Management é responsável por distribuir os arquivos gerados por uma Build
e publicar em um ou mais servidores para lançar uma versão. Este processo é denominado de
Deploy. Permite executar qualquer tarefa necessária para o lançamento completo de uma versão,
tais como execução de script em um servidor de banco de dados, cópia dos arquivos em
determinado local no servidor de aplicação, configuração do servidor de aplicação, etc. Nesta
ferramenta, também é permitido aos administradores do ALM configurar o fluxo de aprovações
necessárias para que uma versão de sistema seja publicada em ambiente de produção.

47
Deverá também ser criado os Releases Templates de cada Build existente para seu ambiente
definido. As convenções/configurações estão definidas no Documento “Padrões de
Desenvolvimento” do DSA. Durante a criação da Release Template, as permissões a ela devem ser
atribuídas conforme o documento de Permissões no ALM.
Figura 11 – Fluxo de uma release
Só é possível criar uma Release Template a partir de uma Build existente.
7.1.5.4.7 Reporting Services
Reporting Services é um recurso que permite a visualização e criação de relatórios extraindo
informações de todas as ferramentas do ALM. Durante a criação de um projeto no TFS, alguns
relatórios são criados por padrão e servem como base para estratificar informações estatísticas
como “Quantidade de Bugs”, “Builds realizadas”, “Quantidades de Tarefas”, etc.

48
As permissões deverão ser atribuídas aos grupos da equipe no diretório do projeto para que estes
possam utilizar estes recursos. As permissões que devem ser atribuídas e os grupos que irão recebe-
las estão descritas no documento Permissões no ALM.
7.1.5.4.8 Sharepoint
Sharepoint é uma ferramenta para colaboração entre as equipes, disponibilização de artefatos
referente aos projetos, entre outros recursos. As permissões para a utilização dessa ferramenta
deverão ser atribuídas aos grupos da equipe no portal do projeto para que estes possam utilizar os
recursos do portal. As permissões serão concedidas de acordo com o documento Permissões no
ALM.
7.1.5.4.9 IIS (Servidor de Aplicação)
IIS é o Servidor de aplicação onde fica hospedada um sistema. Este servidor deversá ser
configurado em cada ambiente para que aponte para o local onde o Release Management fará o
Deploy dos arquivos.
7.1.5.4.10 Ambientes
O publicador do ALM é responsável por validar que as Builds, Releases Templates e Servidores
de Aplicação (IIS) estejam compatíveis e configuradas de acordo para que seu fluxo funcione de
forma rápida e célere. Os objetivos de cada ambiente são:
 Ambiente de Desenvolvimento: Onde o desenvolvedor executa alterações e pode
visualizar a partir da sua própria branch. Normalmente é para desenvolver e testar uma
pequena feature.
 Ambiente de Teste: Onde a equipe de qualidade pode testar uma versão completa do
sistema.
 Ambiente de Homologação: Onde é testado o impacto das modificações a serem feitas em
produção e também onde o teste de aceitação é realizado.
 Ambiente de Produção: Ambiente onde os usuários finais utilizam o sistema.

49
7.1.5.5 Documentar requisitos de negócio
Existem diversos tipos de requisitos que são normalmente classificados em níveis e são derivados
do mais alto nível ao mais baixo nível e a partir do problema de negócio é possível identificar os
requisitos de negócio.
Requisito de negócio é a definição de como o negócio funciona, ela evidencia as restrições
existentes para o funcionamento de determinado negócio, podendo abranger qualquer assunto.
Além disso, a regra de negócio não depende da existência de um sistema. Os requisitos de negócios
deverão ser cadastrados no Team foundation server no formato de Features conforme a Figura 12
– Relação requisitos x work items.
Figura 12 – Relação requisitos x work items
7.1.5.6 Elaborar plano de entregas (release)
O plano de entregas estabelece a meta da versão, as maiores prioridades do Product Backlog, os
principais riscos e as características gerais e funcionalidades que estarão contidas na versão. Ele
estabelece também uma data de entrega e custo prováveis que devem se manter se nada mudar. A
organização pode então inspecionar o progresso e fazer mudanças nesse plano da versão para
entrega a cada Sprint.
Requisitos de negócio
Requisitos funcionais e
não funcionais
Especificações
(requisitos detalhados)
Feature
User story
Task

50
O plano de release define quando as funcionalidades ou um conjunto delas serão entregues ao
cliente. Seu principal objetivo é permitir que o time de desenvolvimento tenha uma visão de quando
as entregas serão efetuadas ao cliente.
7.1.6 CONCEPÇÃO DA APLICAÇÃO: SAÍDAS
 Epics (lista de funcionalidades);
 Plano de release;
 Políticas do ALM;
 Team collection do projeto;
 Portal do sistema;
 Portal do projeto.

51
8 FASE DE CONSTRUÇÃO
Esta fase está essencialmente relacionada à codificação e teste do sistema ou componente, ao final
deve-se ter um sistema de software em funcionamento e a documentação associada pronta para ser
liberada para os usuários (SENE, 2011).
É na fase de construção que a maior parte de codificação ocorre. É prevista para ocorrer de forma
iterativa e incremental, de acordo com o plano de releases criado na atividade Elaborar plano de
entregas (release).
As iterações são um time box4 de aproximadamente 2 a 4 semanas. Se todas as funcionalidades
demandarem esforço inferior a 4 semanas, sugere-se a utilização de apenas uma iteração. Caso a
duração seja superior, a construção deve considerar múltiplas iterações, com a priorização do que
deve ser implementado na iteração ocorrendo no início da mesma, conforme fluxo a ser
apresentado na próxima seção. Esta fase é composta pelos seguintes processos e subprocessos:
1.1. Desenvolvimento da aplicação
1.1.1. Planejar iteração
1.1.2. Executar iteração
1.1.2.1. Construção e testes unitários
1.1.2.2. Planejar testes
1.1.2.3. Executar testes
1.1.2.4. Gestão do conhecimento
8.1 Desenvolvimento da aplicação
O processo de Desenvolvimento da aplicação é responsável por organizar as iterações e executar a
construção da melhoria. A parte mais relevante deste processo ocorre dentro da iteração onde estão
a maior parte das atividades executadas. Iterações são eventos com duração fixa onde o time busca
4 Termo utilizado em métodos ágeis que representa o prazo inflexível de tempo alocado para uma tarefa específica.

52
sempre atingir a meta que foi estabelecida. Tanto a composição do time quanto as metas de
qualidade devem permanecer constantes durante a iteração (SCHWABER, 2009).
As iterações consistem na reunião de planejamento, o trabalho de desenvolvimento e a revisão da
iteração. A retrospectiva da iteração é opcional para as equipes e ocorre dentro da fase de
monitoramento e controle. As iterações deverão ocorrer uma após a outra, sem intervalos entre
elas.

53
Figura 13 – Diagrama de do processo Desenvolvimento da aplicação

54
Atividades do processo Desenvolvimento da
aplicação
Coordenador
AssessoriadaCTI
DiretordoDSA
AssessoraDSA
Gerentedesistemas
Controller
Arquitetodesistemas
Analistadesistemas
Desenvolvedor
Gerentedequalidade
Analistadequalidade
Técnicodequalidade
Cliente
Levantar requisitos A/R C
Registrar user stories no product backlog A/R R
Planejar iteração R/A C C C
Executar iteração A/R R R R
Gerar build stable C/I A/R I I I

55
8.1.1 DESENVOLVIMENTO DA APLICAÇÃO: ENTRADAS
 Requisitos de negócio
 Plano de release
8.1.2 DESENVOLVIMENTO DA APLICAÇÃO: ATIVIDADES
8.1.2.1 Levantar requisitos
É essencial que os requisitos sejam completos, claros, corretos e consistentes, porque eles servem
como pilares da solução para as necessidades do negócio (Guia BABOK®, 2011).
Podem ser utilizadas diversas técnicas durante a execução desta atividade, porém a mais
amplamente aceita pelos os clientes do DSA é para levantamento de requisitos é a aplicação de
entrevistas e questionários.
Durante a atividade de levantamento de requisitos é essencial que os critérios de aceitação sejam
especificados junto ao cliente, pois é por meio destes que os testes serão executados e as
funcionalidades serão validadas pelo cliente.
Todos os documentos gerados no levantamento de requisitos, tais como atas, caso de uso,
modelos dentre outros, deverão ser armazenados na pasta Shared documents, que está localizada
dentro do portal do sistema, na subpasta
8.1.2.2 Registrar user stories no Product Backlog
O product backlog pode ser formado por diversos itens, como requisitos funcionais, requisitos não-
funcionais, correções ou outros itens que agregam valor ao produto (WEISS, 2013), porém para
esta metodologia o item a ser utilizado será a User Story5 quando se tratar de um requisito. As user
stories podem ser cadastradas utilizado o Team web access. As informações obrigatórias no
cadastro de uma user storie são:
5 A user story (história de usuário), é uma descrição concisa de uma necessidade do usuário do produto (ou seja, de
um “requisito”) sob o ponto de vista desse usuário. A User Story busca descrever essa necessidade de uma forma
simples e leve.

56
Figura 14 – Cadastro de user story no team web access
 Título: Breve descrição do que a história irá entregar.
 Details: Forneça detalhes suficientes para fazer a estimativa do trabalho necessário para
implementar a história. Foque no objetivo do recurso, no que os usuários desejam fazer e
por quê. Não descreva como o recurso deve ser desenvolvido. Forneça detalhes suficientes
para que sua equipe possa escrever tarefas e casos de teste para implementar o item. Veja
um exemplo dos detalhes de uma user story na Figura 15 – Formato dos detalhes de uma
user story
 Assigned to: O proprietário da user story. De forma simplista, é o usuário ou o interessado
em um funcionalidade.
 State: Quando o item de trabalho é criado, o status assume por padrão o valor New.
Conforme o trabalho progride, atualize-o para refletir o estado atual.
 Story points: Estimativa da quantidade de trabalho necessária para concluir uma user story
usando qualquer unidade de medida que sua equipe preferir.

57
 Area: Escolha o caminho de área associado ao produto ou à equipe, ou deixe em branco até
ser atribuído durante uma reunião de planejamento.
 Iteration: Iteração em que o trabalho deve ser concluído, ou deixe em branco e atribua
posteriormente, durante uma reunião de planejamento.
Figura 15 – Formato dos detalhes de uma user story
Fonte: Adaptada de (WEISS, 2013)
Após registrar as user stories no Product backlog o fluxo deve ser direcionado para o processo
Planejar iteração.
8.1.2.3 Planejar iteração
O processo de Planejar iteração é uma reunião na qual estão presentes o cliente, o e todo o time6
de desenvolvimento, bem como qualquer pessoa interessada que esteja representando a gerência
ou o cliente (Sprint Planning Meeting, 2013).
O objetivo da primeira parte da reunião é entender o que cada user story representa e em seguida
selecionar quais serão desenvolvidas dando origem ao backlog da iteração. Coletivamente, o time
e o cliente definem um objetivo para o iteração, que é uma breve descrição daquilo que se tentará
alcançar.
6 No scrum um time é composto por três papéis: Scrum máster, product owner e a equipe

58
Na segunda parte da reunião de planejamento da iteração, a equipe7 se encontra separadamente,
sem o cliente, para conversar sobre como será desenvolvida cada user story e o quanto eles podem
se comprometer a fazer na iteração que será iniciada. Em alguns casos, haverá negociação com o
cliente, mas será sempre responsabilidade da equipe determinar o quanto ela será capaz de se
comprometer a fazer.
7 A equipe scrum é que desenvolve e testa o produto.

59
Figura 16 – Diagrama do processo planejar iteração
Tabela 3 – Matriz de responsabilidade planejar iteração

60
Atividades do processo Gerenciamento da
demanda
Coordenador
AssessoriadaCTI
DiretordoDSA
AssessoraDSA
Gerentedesistemas
Controller
Arquitetodesistemas
Analistadesistemas
Desenvolvedor
Gerentedequalidade
Analistadequalidade
Técnicodequalidade
Cliente
Explicar user stories ao time A/R
Selecionar itens do backlog para iteração R R A/R
Decompor user stories em tasks R R
Estimar prazos para as tasks I C C R/C C C
Distribuir tasks A/R

61
8.1.2.3.1 Planejar iteração: Entradas
 Capacidade do time: É um valor que representa a capacidade produtiva ou velocidade de
um time. É o mesmo que definir quantas histórias um time consegue entregar numa iteração,
baseando-se no histórico do time.
 Backlog do produto priorizado: Backlog ordenado com as user story de maior valor para
o negócio em primeiro lugar da lista. Para que o product backlog já esteja priorizado é
necessário executar regularmente o processo Backlog Grooming.
 Incremento do produto recente: Conjunto de funcionalidades potencialmente entregável
que foram desenvolvidas durante uma iteração. Incremento de produto
8.1.2.3.2 Planejar iteração: Atividades
8.1.2.3.2.1 Explicar user stories ao time
Esta atividade deve ser executada preferencialmente pelo cliente, porém existem projetos nos quais
o cliente não se envolve com o processo de desenvolvimento. Nesses casos deverá ser elencado
uma pessoa para representar o cliente durante as reuniões.
O cliente ou seu representante não precisa descrever todos os itens que estão no product backlog.
Dependendo do tamanho do Product Backlog e da velocidade da equipe, pode ser suficiente
descrever apenas os itens de maior prioridade, deixando a discussão dos itens de menor prioridade
para a próxima reunião de planejamento da iteração.
Nota: Para se executar esta atividade é necessário que o product backlog já esteja priorizado. Esta
priorização é feita na atividade de Backlog Grooming fase de

62
Monitoramento e controle.
8.1.2.3.2.2 Selecionar itens do product backlog
Depois de entender e estimar a complexidade dos itens de backlog o time de desenvolvimento
seleciona, respeitando a prioridade, os itens que acredita que consegue entregar na iteração e acorda
estes com o cliente, formando assim o backlog da iteração.
Para executar esta atividade é necessário que o backlog já esteja priorizado. Esta atividade é feita
regularmente no Backlog Grooming.
8.1.2.3.2.3 Decompor user stories em tasks
O time de desenvolvimento discute como entregar cada um dos itens selecionados e quais são as
tarefas (tasks) que precisam ser feitas. São discutidos todos os tipos de atividades que podem ser
necessárias, podendo ser dos seguintes tipos:
 Desenvolvimento
 Deploy
 Desenho
 Documentação
 Levantamento de requisitos
 Teste
8.1.2.3.2.4 Estimar prazos para as tasks
As tarefas deverão ser estimadas em horas e os responsáveis pelas atividades devem informar
quanto tempo será necessário para executar a atividade.
É importante que os prazos inseridos nas tarefas sejam realistas, pois será por meio deles que a
equipe poderá acompanhar se a meta da iteração será alcançada dentro do prazo acordado.
8.1.2.3.2.5 Distribuir tasks
As tarefas devem ser distribuídas para os responsáveis pela execução Para isso basta assinar a tarefa
com o nome de quem a executará. Para fazer a distribuição das tarefas siga os passos abaixo:
1. Entre no Team Foundation Server (TFS) por meio de um navegador;

63
2. Procure pelo projeto desejado;
3. Clique na aba Work;
4. Clique em backlog;
5. Escolha a iteração atual;
Visualize os detalhes de cada tarefa e no campo Assigned to atribua o nome de quem executará a
tarefa. Faça isso para todas as tarefas de todas as histórias.
8.1.2.3.3 Planejar iteração: Saídas
 Backlog da iteração: Os itens selecionados do backlog do produtos mais as tarefas
necessárias para transformá-los em incremento de software pronto e potencialmente
utilizável é. Após a execução do fluxo planejar iteração deve ser direcionado para o fluxo
executar iteração.

64
8.1.2.4 Executar iteração
O processo de executar iteração é onde os desenvolvedores e testadores trabalham com mais
intensidade, é basicamente a codificação e teste ocorrem de forma a concluir os itens do backlog
da iteração.
O processo de Executar iteração pressupõe que o desenvolvimento da aplicação e os testes sejam
realizados em paralelo ao longo de todo o processo de desenvolvimento conforme explica
(BASTOS, RIOS, et al., 2007).

65
Figura 17 – Diagrama Executar iteração
Tabela 4 – Matriz de responsabilidade Executar iteração

66
Atividades do processo Executar Iteração
Coordenador
AssessoriadaCTI
DiretordoDSA
AssessoraDSA
Gerentedesistemas
Controller
Arquitetodesistemas
Analistadesistemas
Desenvolvedor
Gerentedequalidade
Analistadequalidade
Técnicodequalidade
Cliente
Construção e testes unitários R/A
Planejar testes C C R/A
Lançar versão beta R/A I
Executar testes de sistema C R/A
Gestão do conhecimento Ck A R R I
Lançar versão RC A/R

67
8.1.2.4.1 Executar iteração: Entradas
 Tasks
8.1.2.4.2 Executar iteração: Atividades
8.1.2.4.2.1 Construção e testes unitários
A contrução e testes unitários é uma atividade exclusiva da equipe de desenvolvimento. O
desenvolvedor escreve o código necessário e faz alguns testes preliminares, utilizando a análise de
código e ferramentas de teste de unidade estáticos.

68
Figura 18 – Diagrama do processo Construção e testes unitários

69
Tabela 5 – Matriz de responsabilidade Construção e testes unitários
Atividades do processo Construção e testes
unitários
Coordenador
AssessoriadaCTI
DiretordoDSA
AssessoraDSA
Gerentedesistemas
Controller
Arquitetodesistemas
Analistadesistemas
Desenvolvedor
Gerentedequalidade
Analistadequalidade
Técnicodequalidade
Cliente
Puxar Task A/R
Codificar Incremento A/R
Realizar Check in A/R
Gerar build alpha A/R I
Testes Unitários automatizados A/R
Marcar user stories como resolved A/R

70
8.1.2.4.2.1.1 CONSTRUÇÃO E TESTES UNITÁRIOS: ENTRADAS
 Task
 Padrões de desenvolvimento DSA
8.1.2.4.2.1.2 CONSTRUÇÃO E TESTES UNITÁRIOS: ATIVIDADES
8.1.2.4.2.1.2.1 Puxar task
Nesta atividade o desenvolvedor utiliza a própria IDE de desenvolvimento para iniciar a execução
de seu trabalho. O principal objetivo desta atividade é marcar a task com o status Active. Para isso
o desenvolvedor deverá procurar a task utilizando a ferramenta Team Explorer localizada em View
 Team explorer. Em seguida procure pela opção Work Items e na seção Queries procure pela
query My tasks.
Visualize os detalhes na task que deseja iniciar o trabalho e em seguida altere seu status para Active,
salve e inicie o trabalho.
Caso o desenvolvedor possua o Visual Studio Premium ou superior é possível utilizar a opção
my work dentro do team explorer para dar andamento nas tasks ou outros tipos de work items
que estejam assinador para ele.
8.1.2.4.2.1.2.2 Codificar incremento
Nesta etapa o desenvolvedor começa a codificar de acordo com as normas estabelecidas no
documento “Padrões de desenvolvimento” localizado em: Padrões de Desenvolvimento.
Para todos os novos projetos ou onde for possível, deve-se criar os testes unitários que será
utilizado para validar o código.
Durante este desenvolvimento, qualquer mudança referente a arquitetura do sistema deve ser
acordado com o arquiteto da equipe.
8.1.2.4.2.1.2.3 Realizar check in
Realizar check in é o processo de envio do código realizado localmente na estação de trabalho do
desenvolvedor para o TFS.

71
Para executar esta ação no Visual Studio, abra a Solution Explorer (Menu View  Solution
Explorer) e clique com o botão direito no item cujo seus respectivos itens abaixo na hierarquia será
enviado e clicar em Source Control  Check In. Irá então abrir o “Team Explorer” na área de
“Pending Changes”, nesta deve-se informar em Comment as informações sobre o que representa
estas alterações e em Related Work Items deve-se adicionar os work items que estão relacionados
a estas alterações. Após isto é somente clicar em Check In para que as informações sejam enviadas
para o servidor.
Todos os check in devem obrigatoriamente possuir um comentário e um work item vinculado
definido pela política do projeto.
Ao realizar o check in, é gerada uma Build do tipo Alpha e realizado automaticamente o deploy
pela ferramenta “Release Management”. A Build Alpha está ligada a uma branch de
desenvolvimento (Dev) o que significa que esta build é para ser validada e testada somente naquela
feature que originou a Branch.
8.1.2.4.2.1.2.4 Testes Unitários Automatizados
Os testes unitários consistem em validar dados válidos e inválidos via I/O (entrada/saída) sendo
aplicado por desenvolvedores ou analistas de teste. Uma unidade é a menor parte testável de um
programa de computador. Esses testes devem ser executados automaticamente em cada build
criada, o que permite verificar a cobertura de código, quantidade de testes falhos e teste de impacto.
8.1.2.4.2.1.2.5 Marcar User Story como Resolved
O status da user story é marcado como resolved quando seu código já está completo, ou seja,
quando todas as tarefas de desenvolvimento já foram concluídas, e nenhum defeito foi encontrado
nos testes unitários, conforme pode ser visto na Figura 19 – Diagrama de status da user story.

72
Figura 19 – Diagrama de status da user story
Fonte: (MSDN, 2013)
8.1.2.4.2.1.3 CONSTRUÇÃO E TESTES UNITÁRIOS: SAÍDAS
 User story construída

73
8.1.2.4.2.2 Planejar testes
Cada cenário será representado por um conjunto de casos de teste a ser validado por uma lista de
procedimentos, incorporados numa suíte de testes que posteriormente será executada. Os casos de
testes estabelecem quais informações serão empregadas durante os testes desses cenários, quais os
resultados esperados e a massa crítica de testes necessária para validar todos os requisitos de
software.
O plano de caso de teste é o documento que registra todo o planejamento dos testes dos requisitos
estabelecidos durante o ciclo de desenvolvimento do software. Esse documento determina o que
será testado, e seu principal objetivo consiste em identificar o maior número de cenários e variações
de determinado requisito de software (BASTOS, RIOS, et al., 2007).

74
Figura 20 – Diagrama do processo Planejar testes

75
Tabela 6 – Matriz de responsabilidade Planejar testes
Atividades do processo Planejar testes
Coordenador
AssessoriadaCTI
DiretordoDSA
AssessoraDSA
Gerentedesistemas
Controller
Arquitetodesistemas
Analistadesistemas
Desenvolvedor
Gerentedequalidade
Analistadequalidade
Técnicodequalidade
Cliente
Receber task R
Organizar suítes de teste A/R
Elaborar / resetar casos de teste A/R
Reconhecer defeito(s) C R
Corrigir defeito R
Agendar correção A/R R
Encerrar o Bug R
Solicitar teste A/R

76
8.1.2.4.2.2.1 PLANEJAR TESTES: ENTRADAS
 Task de teste
 Critérios de aceitação
8.1.2.4.2.2.2 PLANEJAR TESTES: ATIVIDADES
8.1.2.4.2.2.2.1 Recebertask
Antes de começar a realizar o planejamento dos testes é necessário que uma task já esteja
cadastrada na user story a ser testada. A task para planejar os testes deverá ser escrita durante o
processo de Planejar iteração, onde são definidos quais tarefas são necessárias para a entrega
daquele pacote, no caso a user story.
Para receber a task de teste siga os passos abaixo:
1. Abra o Microsoft Test Manager;
2. Selecione o projeto desejado;
3. Selecione o plano de teste
4. Clique na aba Track;
5. Abra a pasta Shared queries;
6. Abra a pasta Consutlas equipe de qualidade;
7. Execute a query Minhas tarefas;
8. Visualize os detalhes da task e altere o status para Active
9. Clique em salvar
8.1.2.4.2.2.2.2 Organizar suítes de teste
E recomendável que as as suítes de teste sejam organizadas utilizando o mesmo formato que a
arquitetura do software foi organizada. Os casos de teste devem estar organizados dentro de um
dos seguintes tipos de suítes de teste:
 Suite de teste baseado em requisitos – Inclui qualquer caso de teste que esteja linkado à
uma user story. O mais indicado é que todas as suítes de testes sejam linkadas à algum
requisitos que estão sendo implementados na iteração. Desta forma, é possível criar e

77
executar casos de testes que verificam se a aplicação está entregando o que foi prometida
na funcionalidade.
 Suite baseada em consultas – Permite que seja especificada um conjunto de work items
baseados em uma consulta. Por exemplo, é possível querer incluir todos os casos de teste
com prioridade de nível 1, mesmo se estes requisitos já foram concluídos em outras
iterações. Ajuda a garantir que funcionalidades críticas que já foram implementadas não
foram impactadas pelas novas alterações (teste de regressão).
 Suite de teste estática – Trata-se de uma lista de casos de teste que podem ser adicionadas
manualmente na suíte. Uma suíte de teste estática também pode ser usada como um
contêiner para outras suítes de teste, fornecendo uma estrutura hierárquica para organização
dos testes.
Sempre que possível, utilize a suite de teste baseada em requisitos.
8.1.2.4.2.2.2.3 Elaborar / resetar casos de teste
Na ferramenta Microsoft Test Manager ao clicar na aba Plan  Conteúdo, é possível e organizar
os casos de teste que compõem o Plano de teste. Um caso de teste é um conjunto de interações com
uma aplicação de software que são projetados para validar a funcionalidade ou o comportamento
do aplicativo. Por exemplo, pode existir um caso de teste que confirme que um novo usuário pode
criar uma conta dentro de sua aplicação.
8.1.2.4.2.2.2.4 Solicitar teste
Após a criação do planejamento de teste por meio de suítes de teste e casos de teste, o analista de
qualidade deve solicitar a execução desses testes. Para isso deverá ser aberta uma task de teste. A
abertura da task de teste deverá obrigatoriamente conter os seguintes campos:
1. Título: Nome da tarefa com título intuitivo como: “Testar user story”
2. Assigned to: Responsável por executar os testes;
3. Activity: Deverá ser escolhida a atividade “testing”
4. Details: Descrição de quais casos de testes deverão ser testados.
Após a execução da atividade solicitar teste, deve ser direcionado a execução do Processo Executar
Testes.

78
8.1.2.4.2.2.2.5 Reconhecer defeito(s)
Depois de detectado o defeito, o analista de teste em conjunto com o analista de sistemas devem
verificar e decidir se ele é válido ou não, e analisar sua criticidade. Um defeito que impacta na
release atual deveser corrigido o mais rápido possível, caso contrário sua correção deve ser definida
em qual release esta correção deve ser entregue. Se o defeito reportado pelos técnicos de qualidade
não for válido o fluxo deve ser direcionado para atividade Encerrar o Bug.
8.1.2.4.2.2.2.6 Corrigir defeito
Após o defeito ser reconhecido como válido e também como um defeito crítico, ou seja, um defeito
que irá impactar a release a ser lançada, é necessário realizar a correção deste.
8.1.2.4.2.2.2.7 Agendar correção
Um defeito reconhecido como válido mas não considerado urgente pode ser agendado para ser
corrigido em uma outra iteração. Para isso deve ser iniciado a execução do processo
Desenvolvimento da aplicação.
8.1.2.4.2.2.2.8 Encerrar o Bug
Caso o analista de teste e o analista de sistema identifiquem que o defeito não é válido, o bug deverá
ser encerrado. O status o bug deverá constar como closed e o campo Reason deverá estar marcado
como verified, como pode ser observado na Figura 21 – Transição de status dos bugs no MSF. Para
alterar o status do bug siga os passos abaixo:
1. Acesse o team projeto na ferramenta Team Fondation Web Access;
2. Escolha o projeto desejado;
3. Clique me work;
4. Clique em queries;
5. Procure o bug utilizando uma das queries já cadastradas;
6. Visualize os detalhes dos bugs;
7. Altere o campo State para Closed;
8. Clique em salvar no ícone semelhante a um disquete.

79
O framework da Microsoft MSF não trata dos bugs juntos ao backlog do produto, sendo tratado
em um processo chamado Bug triage, por isso há necessidade de consutlar os bugs por meio de
uma consulta.
Os bugs possuem status diferente das user stories e das tasks, seguindo o fluxo mostrado na Figura
21 – Transição de status dos bugs no MSF.
8.1.2.4.2.2.3 PLANEJAR TESTES: SAÍDAS
 Casos de teste
 Bug encerrado

80
Figura 21 – Transição de status dos bugs no MSF
8.1.2.4.2.3 Lançar versão BETA
A versão beta é lançada após todos os itens previstos na iteração terem sido desenvolvidos e seus
testes planejados. Se algum teste unitário for reprovado a versão beta não poderá ser lançada até
que todos os defeitos primários tenham sido corrigidos.
Para lançar a versão Beta, deve-se fazer um merge da(s) branch(s) de desenvolvimento para a
branch MAIN (ambiente de teste), efetuar o check in e então gerar uma build Beta.
Para saber mais sobre o que cada versão represenda no fluxo do ALM veja a Figura 22 – Ciclo de
vida das releases.

81
Figura 22 – Ciclo de vida das releases
Fonte: Adaptado de (CAMARGO, 2009)
8.1.2.4.2.4 Executar testes de sistema
O responsável pelos testes deve utilizar a ferramenta Test Professional Manager para gerenciar e
executar um conjunto de casos de teste manuais, na intenção de encontrar a maior quantidade
possíveis de defeitos no software e registrar os bugs para a equipe de desenvolvimento.
Embora o ciclo de vida de teste seja totalmente independente do ciclo de vida de desenvolvimento,
os testes só poderão ser executados após a conclusão dos produtos do ciclo de vida de
desenvolvimento (BASTOS, RIOS, et al., 2007).
Os bugs gerados neste processo contêm diversas informações para o desenvolvedor, incluindo um
vídeo do test case executado pelo responsável dos testes (screenshots), log de eventos a partir do
momento que o teste iniciou.
As atividades do ciclo de vida de testes devem ser executadas por um grupo formalmente definido
para a realização dos testes, para que sejam bem realizadas.
Alpha- Versãoemconstruçãoaindanãodisponível parauso
Beta - Primeiraversãodisponibilizadaparaa equipe de qualidade oualguns
usuários.
Release candidate (RC) - Omaispróximodaversãofinal,poisamaioriados
defeitosjáfoi corrigda
Stable - Versãofinal que vai para o ambiente de produção

82
Figura 23 – Diagrama Executar testes de sistema

83
Tabela 7 – Matriz de responsabilidade Executar testes de sistema
Atividades do processo Executar Testes
Coordenador
AssessoriadaCTI
DiretordoDSA
AssessoraDSA
Gerentedesistemas
Controller
Arquitetodesistemas
Analistadesistemas
Desenvolvedor
Gerentedequalidade
Analistadequalidade
Técnicodequalidade
Cliente
Receber task R/A
Procurar defeito(s) R/A
Reprovar caso de teste I R/A
Relatar defeito(s) I I R/A
Encerrar task R/A

84
8.1.2.4.2.4.1 EXECUTAR TESTES DE SISTEMA: ENTRADAS
 Casos de teste
 Task de teste
8.1.2.4.2.4.2 EXECUTAR TESTES DE SISTEMA: ATIVIDADES
8.1.2.4.2.4.2.1 Recebertask
Antes dos testes serem executados é necessário que uma task seja aberta, como forma de registro
da solicitação da execução dos testes. Quem registra essa task é o analista de teste e quem recebe
a task é o técnico de teste. Nesta task de teste deverá conter quais casos de testes deverão ser
testados. Para que o técnico de teste acesse a task deve ser verificado os passos abaixo:
1. Abra o Microsoft Test Manager e selecione a aba Track;
2. Abra a pasta My queries e realize a consulta;
3. Localize a Task desejada e visualize os detalhes
4. Mude o status da task para active.
8.1.2.4.2.4.2.2 Procurar defeitos
Nesta atividade o técnico de teste irá procurar defeitos nas features implementadas por meio de
heurística, ou seja, tenta identificar defeitos no software por meio da análise e interpretação de um
conjunto de princípios. Para executar os testes é necessário abrir a ferramenta test run executando
as seguintes instruções abaixo:
1. Abra o Microsoft Test Manager;
2. Escolha o projeto desejado;
3. Escolha o plano de teste desejado;
4. Selecione qual caso de teste será testado de acordo com a task aberta pelo analista de teste;
5. Clique em run e o test runner será aberto;
6. Realize os testes de acordo com o que foi planejado.
Se precisar interromper a execução do teste, pause o teste, pois qualquer ação que não faça parte
do fluxo básico será capturada pela ferramenta.

85
 Se durante a execução dos testes não for detectados defeitos, o fluxo do processo
deve ser direcionado a atividade encerrar task.
 Se durante a execução dos testes for detectados defeitos, deve ser verificado se os
defeitos são defeitos no fluxo básico.
 Se sim o fluxo deve ser direcionado a atividade Relatar defeito
 Se não o fluxo deve ser direcionado a atividade Reprovar caso de teste
8.1.2.4.2.4.2.3 Reprovar caso de teste
Um caso de teste é reprovado quando o resultado esperado de qualquer um dos passos do caso de
teste não for atendido, em outras palavras quando qualquer passo do caso de teste for marcado
como fail. Esta marcação é feita durante a atividade Procurar defeitos onde é utilizada a ferramenta
Microsoft Test Runner como apoio para esta atividade.
Ao reprovar um caso teste o sistema não cria um bug automaticamente. Se um bug não for
registrado informando que um teste que falhou, o analista de teste ou desenvolvedor saberá que
existe um defeito no software.
8.1.2.4.2.4.2.4 Relatar defeito
Os defeitos devem ser reportados aos analistas de testes, por meio da abertura de um bug na
ferramenta Microsoft Test Manager.
Se estiver adicionando novas informações em um bug existente, clique na seta de bug e em seguida
escolha a opção Update an existing bug para adicionar novos anexos ou outras informações ao bug.
Quando se registra um bug por meio do Test Manager, todos os anexos do teste atual são incluídos
no bug, tornando fácil para os desenvolvedores entender como o defeito foi descoberto e fornece
várias outras informações que podem ser úteis para resolver o bug mais tarde.
É possível também registrar um bug mesmo depois de um teste ter sido executado clicando na aba
Test  Analyze test runs, abrindo o test run, selecionando o test e em seguida clicando em Create
bug.

86
8.1.2.4.2.4.2.5 Encerrar task
A task de execução de teste deve ser encerrada na ferramenta Microsoft Test Manager seguindo os
seguintes passos:
1. Abra o Microsoft Test Manager e selecione a aba Track;
2. Abra a pasta My queries e realize a consulta;
3. Localize a Task desejada e visualize os detalhes
4. Mude o status da task para closed.
8.1.2.4.2.4.3 EXECUTAR TESTES DE SISTEMA: SAÍDAS
 Bugs
 Task de teste encerrada

87
8.1.2.4.2.5 Gestão do conhecimento
Este processo é responsável por disseminar o conhecimento sobre os produtos e serviços
desenvolvidos pelo DSA, seja por meio de treinamentos ou por meio de documentação de apoio.
É importante frisar que este processo deve ser executado sempre que a alteração impactar alguma
das partes interessadas.

88
Figura 24 – Diagrama Gestão do conhecimento

89
Tabela 8 – Matriz de responsabilidade Gestão do conhecimento
Atividades do processo Gestão do
conhecimento
Coordenador
AssessoriadaCTI
DiretordoDSA
AssessoraDSA
Gerentedesistemas
Controller
Arquitetodesistemas
Analistadesistemas
Desenvolvedor
Gerentedequalidade
Gerentedequalidade
Analistadequalidade
Técnicodequalidade
Cliente
Treinar partes interessadas A/R R R
Atualizar documentação do projeto A/R R
Gerar/atualizar documentação de apoio R R

90
8.1.2.4.2.5.1 GESTÃO DO CONHECIMENTO: ENTRADAS
 Incremento do produto pronto
 Releases notes
8.1.2.4.2.5.2 GESTÃO DO CONHECIMENTO: ATIVIDADES
8.1.2.4.2.5.2.1 Treinar partes interessadas
A equipe de qualidade em conjunto com a equipe de desenvolvimento deverá elaborar um plano
de treinamento para os usuários do sistema.
Dependendo da modificação não será necessário executar esta atividade, porém será necessário
realizar a devida comunicação enviando a documentação de apoio, e o documento de release note.
O documento de release notes deverá ser cadastrado na WikiCTI e comunicado via mural de avisos
do sistema SDK. Este documento deve ser escrito com linguagem não técnica de modo que até
mesmo um usuário final consiga interpretá-lo.
8.1.2.4.2.5.2.2 Atualizar documentação do projeto
Alguns work items serão atualizados automaticamente dependendo do projeto, porém existem
entregas que não são. Estas deverão ser atualizadas com o percentual de conclusão, status e outras
informações.
Para fazer isso é necessário acessar a ferramenta web project, procurar o projeto na qual a release
está inserido e atualizar as informações no cronograma.
8.1.2.4.2.5.2.3 Gerar/atualizar documentação de apoio
Sempre que um incremento do produto for gerado é necessário rever a documentação de apoio e
caso não exista, a documentação deve ser criada. A documentação de apoio são os manuis de
sistema, diagramas, processos e POP’s.
8.1.2.4.2.5.3 GESTÃO DO CONHECIMENTO: SAÍDAS
 Comunicação para as partes interessadas
 Diagramas de processos

91
 Documento de release notes
 Manuais de sistema
 Procedimentos operacionais padrão
O documento de release notes, manuais de sistema e procedimentos operacionais padrão deverão
ser cadastrados na WikiCTI
8.1.2.4.2.6 Lançar versão RC
Para lançar a versão RC, deve-se fazer um merge da branch Main para a branch Servicing
(ambiente de homologação), efetuar o check in e então gerar uma build RC. Para mais informações
sobr a organização das branches veja a Figura 10 – Organização das branches na metodologia.
8.1.2.4.3 Executar iteração: Saídas
 Release no ambiente de homologação

92
8.1.2.5 Gerar build stable
A build stable é utilizada quando o pacote de melhorias e correções (release) já está apto para subir
para produção. Para executar esta atividade abra a ferramenta visual Studio.
Já com o Visual Studio aberto clique em View  Team explorer  Builds. Selecione a build com
o nome stable. Em seguida clique com o botão direito em cima da build e selecione a opção Queue
new build. Após isso clique no botão Queue.
Para realizar esta atividade o team explorer do visual Studio deverá estar conectado no projeto
em questão.
8.1.3 DESENVOLVIMENTO DA APLICAÇÃO: SAÍDAS
 Incremento do produto em produção

93
9 FASE DE OPERAÇÃO
A operação ocorre no momento em que a aplicação está construída (pronta), e vamos distribuí- la,
além de mantê-la funcional no ambiente dos clientes e da empresa.
9.1. Gerenciamento de incidentes
9.2. Gerenciamento de liberações

94
9.1 Gerenciamento de incidentes
O processo de gerenciamento de incidentes que tem como principal objetivo restaurar a operação
normal do serviço o mais rápido possível, minimizando os prejuízos à operação do negócio e
garantindo assim o melhor nível de serviço e disponibilidade.
O departamento de sistemas e aplicações tem responsabilidade de reestabelecer o mais rápido
possível o funcionamento de um produto ou serviço por eles disponibilizado. Um incidente pode
ser a parada completa de um serviço ou até mesmo a perda de qualidade deste. A operação normal
do serviço é definida dentro do acordo de nível de serviço que é um outro processo ITIL
(TECHNET, 2014).

95
Figura 25 – Diagrama Gerenciamento de incidentes

96
Tabela 9 – Matriz de responsabilidade Gerenciamento de incidentes
Atividades do processo de Gerenciamento de
incidentes
Coordenador
AssessoriadaCTI
DiretordoDSA
AssessoraDSA
Gerentedesistemas
Controller
Arquitetodesistemas
Analistadesistemas
Desenvolvedor
Gerentedequalidade
Analistadequalidade
Técnicodequalidade
Cliente
Realizar análise inicial R
Realizar suporte C A/R
Encerrar o chamado R I
Encaminhar para o nível 3 R/A
Examinar o problema A/R
Registrar no backlog da Sprint R
Registrar no product backlog A/R
Definir chamado em cronograma A/C R

97
9.1.1 GERENCIAMENTO DE INCIDENTES: ENTRADAS
 Chamado
9.1.2 GERENCIAMENTO DE INCIDENTES: ATIVIDADES
9.1.2.1 Realizar análise inicial
Nessa atividade é realizada a análise inicial do chamado, e em algumas situações quando o
chamado não tiver informações suficientes para análise o responsável pela atividade deve entrar
em contrato com o cliente para levantar mais informações acerca do chamado.
É necessário que o chamado possua o mínimo de informação para dar andamento e caso isso não
ocorra o chamado deverá ser rejeitado pela equipe de qualidade. Para rejeitar o chamado siga os
passos abaixo:
1. Abra o sistema SDK;
2. Procure pelo chamado que deseja rejeitar;
3. Visualise os detalhes do chamado;
4. Clique no botão Rejeitar;
5. Esolha o motivo da devolução;
6. Coloque as observações necessárias e clique me devolver
9.1.2.2 Realizar suporte
No Departamento de Sistemas e Aplicações o suporte inicial é realizado pela Equipe de Qualidade
de Software. Os serviços suportados pela equipe de qualidade são:
 Suporte avançado no uso de sistemas do PJMT
 Criação e atualização de Manual de Sistema
 Criação e atualização de Vídeo Aula
 Implantação de sistemas
 Recebimento de treinamento
 Repasse de treinamento

98
Se o chamado não estiver dentro de nenhum destes serviços ou se a equipe não possuir uma solução
de contorno para um determinado problema, este deverá ser encaminhado para os grupos
especialistas.
9.1.2.3 Encerrar chamado
Após realizar o suporte e conseguir solucionar o problema o chamado deverá ser encerrado na
ferramenta SDK informando com detalhes qual foi solução e marcado com o tipo incidente. É
importante o correto preenchimento das categorias, pois a partir dessas informações que serão
gerados os relatórios para tomada de decisão.
9.1.2.4 Encaminhar para o Nível 3
Após a análise inicial se o responsável pela atividade identificar que não é possível solucionar o
incidente, o chamado deve ser encaminhado ao grupo especialista Nivel 3, seguindo os seguintes
passos:
1. Acessar o sistema SDK;
2. Visualizar o chamado;
3. Selecionar a opção abrir subchamado;
4. Escolher o grupo especialista;
5. Inserir o parecer técnico detalhado;
6. Selecionar a opção “Abrir subchamado”.
O chamado só pode ser encaminhado ao grupo especialista quando o responsável da equipe de
qualidade não conseguir resolver a solicitação do cliente com base nos conhecimentos em
manuais e equipe.
9.1.2.5 Examinar o problema
Quando um chamado chega ao nível especialista é necessário examinar o problema e não somente
o incidente. De acordo com (JOBS, 2009) o processo de gerenciamento de problemas visa
identificar e remover erros do ambiente de TI, através da busca da causa raiz dos incidentes
registrados no Gerenciamento de Incidentes, a fim de garantir uma estabilidade máxima dos
serviços de TI.

Metodologia de Gerenciamento de Projetos Ágil

Metodologia de Gerenciamento de Projetos Ágil

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Metodologia de Gerenciamento de Projetos Ágil

Semelhante a Metodologia de Gerenciamento de Projetos Ágil (20)

Último

Último (6)

Metodologia de Gerenciamento de Projetos Ágil