TCC SauloArruda

UNIVERSIDADE FEDERAL DE
LAVRAS
GERENCIANDO PROJETOS DE ESCOPO

ABERTO: UMA ABORDAGEM ÁGIL
SAULO ARRUDA COELHO
LAVRAS
MINAS GERAIS - BRASIL
2009
SAULO ARRUDA COELHO
GERENCIANDO PROJETOS DE ESCOPO

ABERTO: UMA ABORDAGEM ÁGIL
Trabalho de Conclusão apresentada(o) ao Departamento

de Ciência da Computação da Universidade Federal de
Lavras, como parte das exigências do curso de Pós-
Graduação Lato Sensu em Melhoria de Processo de
Software, para a obtenção do título de especialização.
Orientador
Prof. Geovane Nogueira Lima
LAVRAS
2009
SAULO ARRUDA COELHO
GERENCIANDO PROJETOS DE ESCOPO ABERTO:

UMA ABORDAGEM ÁGIL
Trabalho de Conclusão apresentada(o) ao Departamento

de Ciência da Computação da Universidade Federal de
Lavras, como parte das exigências do curso de Pós-
Graduação Lato Sensu em Melhoria de Processo de
Software, para a obtenção do título de especialização.
Aprovada em ____ de ____________ de _____.
Prof. ________________
Prof. ________________
Prof. ________________
(Orientador)
LAVRAS
2009
AGRADECIMENTOS
Primeiramente gostaria de agradecer a diretoria da Agence por todo apoio e confiança no
trabalho que está sendo realizado. Sabemos que sem apoio da alta direção nenhum programa
de Melhoria de Projetos é possível.
Agradeço também minha família, Érika minha esposa, May e Taila minhas lidas filhas,
por me apoiar em um momento em que temos que conciliar trabalho, responsabilidades e
ainda dedicar-se para fazer um curso de especialização.
Em especial, agradeço os colegas da Agence que foram muito valiosos nas discussões
e deram o máximo de si para fazer o programa de MPS dar resultado.
SUMÁRIO
LISTA DE FIGURAS
..............................................................................................6
LISTA DE TABELAS
..............................................................................................7
1. Introdução
............................................................................................................8
2. Conceitos Relacionados
.......................................................................................8
2.1. Desenvolvimento Ágil
........................................................................................8
2.1.1. Extreme Programming (XP)
............................................................................9
2.1.2. OpenUP/Basic
................................................................................................10
2.2. MPS.BR
.............................................................................................................11
3. Contexto e Motivação
.........................................................................................12
3.1. A Empresa
..........................................................................................................12
3.2. Projetos de Escopo Aberto na Agence
...............................................................13
4. Processo de Desenvolvimento
............................................................................14
4.1. Abordagem Ágil
................................................................................................14
4.2. Modelo do Processo
..........................................................................................15
4.2.1. Estrutura Analítica do Projeto
........................................................................15
4.2.2. Modelo de Ciclo de Vida
................................................................................16
4.2.2.1. Iteração de Prospecção
................................................................................16
4.2.2.2. Iteração de Construção
................................................................................17
4.2.2.3. Iteração de Transição
...................................................................................19
4.2.3. Papéis
.............................................................................................................19
4.3. Perfil de Capacidade do Processo
......................................................................22
4.4. Soluções do Processo para o MPS.BR
..............................................................23
4.4.1. GPR - Gerência de Projetos
...........................................................................23
4.4.2. GPR - Gerência de Requisitos
........................................................................26
4.4. Adaptações do Processo
....................................................................................27
5. Conclusão
............................................................................................................27
REFERÊNCIAS BIBLIOGRÁFICAS
.................................................................29
ANEXOS
.................................................................................................................30
LISTA DE FIGURAS
Figura 1 - O ciclo de vida do OpenUP/Basic
.......................................................................11
Figura 2 - Fluxo dos Processos da Iteração de Prospecção
.................................................17
Figura 3 - Fluxo dos Processo da Iteração de Construção
...................................................18
Figura 4 - Fluxo dos Processos da Iteração de Transição
....................................................19
LISTA DE TABELAS
Tabela 1 - Expectativas do cliente e do fornecedor de contratos de escopo aberto
.............13
Tabela 2 - Processos, Papéis e Artefatos do Agence PDS EA
.............................................20
Tabela 3 - Relação de Modelos de Documentos Anexos
.....................................................23
Gerenciando Projetos de Escopo Aberto: Uma
Abordagem Ágil¹
¹Departamento de Ciência da Computação - Universidade Federal de

Lavras
Lavras - MG - Brasil
saulo.arruda@agence.com.br
Abstract. This paper propose a process model to manage open scope projects in
Agence Consultoria. The process uses agile development pratices and is designed
for compatibility with the level G of MPS.BR model.
Resumo. Este artigo propõe um modelo de processo para gerenciamento de

projetos de escopo aberto da Agence Consultoria. O processo se utiliza de práticas
de desenvolvimento ágil e modelado para compatibilidade com o nível G do
modelo MPS.BR.
1. Introdução
A demanda cada vez maior por produtos e serviços de software vem exigindo das empresas
fornecedoras mais qualidade a um custo e prazo menores. O desafio das organizações
intensivas é aumentar a produtividade da equipe e qualidade dos produtos e serviços.
A Agence Consultoria e Desenvolvimento para Web Ltda é uma empresa sediada em
Campo Grande/MS, com sua unidade de produção, e em São Paulo/SP, com sua unidade de
negócios. A Agence atua há 10 anos com desenvolvimento de aplicações para Web atendendo
grandes clientes do cenário nacional como Toyota, Bradesco, Vivo, Honda, Pirelli, TIM, entre
outros.
Desde 2008 a Agence vem trabalhando na melhoria de seus processos internos. Este
trabalho vem mostrando resultados significativos em ganho de produtividade e satisfação de
clientes.
Este artigo apresenta uma proposta de processo de desenvolvimento para projetos de
escopo aberto em conformidade com o modelo MPS.BR e fazendo uso extensivo de práticas
ágeis.
2. Conceitos Relacionados
A seguir, são apresentados alguns conceitos amplamente citados neste artigo.
2.1. Desenvolvimento Ágil
Em fevereiro de 2001 setenta pessoas se reuniram para conversar, esquiar, relaxar e encontrar
um terreno comum, além, lógico, de comer bem. O que surgiu desse encontro foi o Manifesto
Ágil de Desenvolvimento de Software (Manifesto for Agile Software Development) [Beck,
Beedle, Bennekum et al. 2001][Agile Manifesto 2009]. Esse grupo veio a se tornar a Aliança
Ágil (The Agile Alliance) [Agile Alliance 2009].
O Manifesto Ágil de Desenvolvimento de software prega que [Agile Manifesto 2009]:
• Indivíduos e iterações entre eles vem antes de processos e ferramentas
• Software funcionando vem antes de documentação abrangente
• Colaboração do cliente vem antes de negociação de contrato
• Resposta à mudanças vem antes de um plano em andamento
8
O encontro também rendeu uma lista de treze princípios que vem por trás do
Manifesto Ágil [Agile Manifesto 2009]:
1. Nossa prioridade mais alta é satisfazer o cliente por meio de entrega pronta e contínua
de software de valor.
2. Acolher mudanças nos requisitos, mesmo no final do desenvolvimento. Processos
ágeis valorizam a mudança para vantagem competitiva do cliente.
3. Entrega software funcionando com freqüência (de várias semanas a vários meses),
preferencialmente usando uma escala de tempo menor.
4. O pessoal do negócio e os desenvolvedores devem trabalhar juntos diariamente ao
longo do projeto.
5. Construir projetos em volta de indivíduos motivados. Dê a eles o ambiente e o apoio
que necessitam e confie que eles vão fazer o serviço.
6. O método mais eficiente e efetivo para leva informação de e para uma equipe de
desenvolvimento é a conversa face a face.
7. Software funcionando é a principal medida de progresso.
8. Processos ágeis promovem desenvolvimento sustentável.
9. Os patrocinadores, desenvolvedores e usuários devem poder manter um ritmo
constante indefinidamente.
10. Atenção contínua para excelência técnica para um bom projeto aumenta a agilidade.
11. Simplicidade - a arte de maximizar a quantidade de trabalho não realizada - é
essencial.
12. As melhores arquiteturas, requisitos e projetos surgem de equipes auto-organizadas.
13. Em intervalos regulares, a equipe reflete sobre como se tornar mais efetiva, depois
sintoniza e ajusta seu comportamento de acordo com isso.
[Larman 2007] explica que métodos de desenvolvimento ágil usualmente aplicam
desenvolvimento iterativo e evolutivo de tempo limitado, empregam planejamento adaptativo,
promovem entrega incremental e incluem outros valores e práticas que encorajam agilidade -
reposta rápida e flexível à modificação.
Os principais Métodos Ágeis conhecidos no mercado são [Wikipedia 2009]: Agile
Modeling, Agile Unified Process, Agile Data Method, DSDM, Essential Unified Process,
Extreme Programming, Feature Driven Development, Getting Real, Open Unified Process/
Basic (OpenUP/Basic), Scrum, Lean Software Development.
Mais informações sobre desenvolvimento ágil podem ser encontradas em
www.agilealliance.com. [Agile Alliance 2009]
Os dois métodos ágeis que mais se destacam para este trabalho são Extreme
Programming e OpenUP/Basic. A seguir uma breve descrição sobre eles:
2.1.1. Extreme Programming (XP)
Segundo [Beck 1999], o problema básico do desenvolvimento de software são os riscos.
Alguns exemplos: atraso de prazos, cancelamento do projeto, sistema “azedar”, grande
quantidade de defeitos, mal entendimento ou mudanças do negócio, funcionalidades de pouco
valor agregado, rotatividade da equipe. Extreme Programming (XP) é uma disciplina de
desenvolvimento de software que trata os riscos em todos os níveis do processo de
desenvolvimento.
9
[Teles 2004] explica que XP é um processo de desenvolvimento de software voltado
para:
• Projetos cujos requisitos são vagos e mudam com freqüência;
• Desenvolvimento de sistema orientados a objeto;
• Equipes pequenas, preferencialmente até 12 desenvolvedores;
• Desenvolvimento incremental (ou iterativo), onde o sistema começa a ser
implementado logo no início do projeto e vai ganhando novas funcionalidades ao
longo do tempo.
Complementa ainda que o XP é um processo de desenvolvimento que busca assegurar
que o cliente receba o máximo de valor de cada dia de trabalho da equipe de
desenvolvimento. Ele é organizado em torno de um conjunto de valores e práticas que atuam
de forma harmônica e coesa para assegurar que o cliente sempre receba um alto retorno do
investimento em software.
Os valores do XP são: feedback, comunicação, simplicidade e coragem. Enquanto as
práticas são: cliente presente, jogo do planejamento, reunião de pé, programação em par,
desenvolvimento dirigido por testes, refatoração, código coletivo, código pradronizado,
design simples, metáfora, ritmo sustentável, integração contínua e releases curtos [Teles
2004].
2.1.2. OpenUP/Basic
Segundo [Eclipse 2006], o OpenUP/Basic é um processo de desenvolvimento de
software de código aberto projetado para equipes pequenas e co-localizadas que querem ter
uma abordagem ágil para desenvolvimento. O OpenUP/Basic é um processo iterativo que é
Mínimo, Completo e Extensível, valorizando a colaboração entre a equipe e os benefícios aos
interessados ao invés da formalidade e entregáveis desnecessários.
O OpenUP/Basic é caracterizado por quatro princípios mutuamente suportados:
• Colaborar para alinhar interesses e compartilhar entendimento
• Balancear as prioridades (necessidades e custos técnicos) para maximizar o valor dos
interessados
• Focar na articulação da arquitetura para facilitar a colaboração técnica, reduzir o
risco, e minimizar o sucateamento e o retrabalho.
• Evoluir continuamente para reduzir riscos, demonstrar resultados, e ganhar feedback
do cliente.
O OpenUP/Basic é um processo iterativo distribuído por quatro fases: Concepção,
Elaboração, Construção e Transição. Cada fase consiste de uma ou mais iterações, onde
versões estáveis do software são desenvolvidas e liberadas, com a conclusão de cada iteração
representando um pequeno marco para o projeto e contribuindo para a realização bem
sucedida do marco principal da fase, onde os objetivos da fase são alcançados.
O diagrama a seguir descreve o ciclo de vida do OpenUP/Basic:
10
Figura 1 - O ciclo de vida do OpenUP/Basic
2.2. MPS.BR
O MPS.BR foi criado em 2003, coordenado pela Associação para Promoção da Excelência do
Software Brasileiro (SOFTEX), com o apoio do Ministério da Ciência e Tecnologia (MCT),
Financiadora de Estudos e Projetos (FINEP), Serviço Brasileiro de Apoio às Micro e
Pequenas Empresas (SEBRAE) e Banco Interamericano de Desenvolvimento (BID) [Softex
2009].
O MPS.BR baseia-se nos conceitos de maturidade e capacidade de processo para
avaliação e melhoria da qualidade e produtividade de produtos de software e serviços
correlatos. Desta forma, o modelo MPS possui três componentes: Modelo de Referência (MR-
MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS).
Segundo [Salviano 2006], capacidade de processo está relacionada com a habilidade
de o processo ser executado de forma eficiente e eficaz. O termo capacidade é utilizado como
uma tradução do termo em inglês capability. O objetivo é ter um processo com as seguintes
características:
• Praticado: ser executado de forma consistente sempre que necessário;
• Documentado: estar descrito em alguma notação de representação de processo,
utilizando texto, figuras etc., correspondendo a como o processo é executado;
• Treinado: as pessoas que realizam atividades do processo devem ter o conhecimento,
habilidade e experiência, necessários para o trabalho;
• Controlado: os artefatos do processo devem ser controlados para garantir sua
integridade e disponibilidade, e propostas de mudanças devem ser analisadas,
aprovadas, planejadas e realizadas antes que sejam institucionalizadas;
• Apoiado: equipe de apoio, ferramentas e outros recursos apropriados devem ser
disponibilizados para apoiar a realização do processo;
• Mantido: deve ser alterado para suportar uma evolução contínua;
• Apropriado: deve ajudar as pessoas a realizar o trabalho, e não ser mais um problema
a atrapalhar;
• Flexível: deve permitir certa flexibilidade em como o processo é executado, para
melhor adaptação baseado em necessidades específicas;
• Medido: medidas de produto e processo devem ser realizadas, consolidadas e
analisadas para um melhor entendimento da capacidade do processo; e
• Melhorado: deve ser melhorado constantemente para reduzir variações e eliminar
esperdícios.
11
O modelo MPS conta como base técnica para sua elaboração as normas ISO/IEC
12207:2008 e ISO/IEC 15504-2. O MR-MPS foi definido em conformidade com o CMMI-
DEV e define sete níveis de maturidade: [Softex 2009]
• A - Em otimização
• B - Gerenciado Quantitativamente
• C - Definido
• D - Largamente Definido
• E - Parcialmente Definido
• F - Gerenciado
• G - Parcialmente Gerenciado
Essa definição em sete níveis tem o objetivo de possibilitar uma implementação e
avaliação adequada às micros, pequenas e médias empresas.A possibilidade de se realizar
avaliações considerando mais níveis também permite uma visibilidade dos resultados de
melhoria de processos em prazos mais curtos.
3. Contexto e Motivação
3.1. A Empresa
A Agence Consultoria atua há 10 anos no mercado de desenvolvimento de software para Web,
atendendo clientes como Vivo, Toyota, Bradesco, Oi, Honda, entre outros. A empresa atua
principalmente com desenvolvimento de software sob medida, realizando todas as etapas do
ciclo de vida do projeto.
Atualmente a empresa conta com cerca de 80 colaboradores na equipe de
desenvolvimento e possui escritórios em Campo Grande/MS, concentrando boa parte da
equipe de produção e São Paulo/SP, concentrando a equipe de gerenciamento de projetos e
negócios.
A Agence iniciou em 2008 um programa interno de Melhoria de Processo de Software
usando a abordagem PDCA (Plan Do Check Act) [Deming 1986]. O objetivo desse programa
inicialmente era buscar uma melhoria nos processos internos visando aumento da
produtividade e maior satisfação do cliente. Com o andamento dos trabalhos a empresa viu
uma boa oportunidade para investir na obtenção de uma certificação MPS.BR prevista para
2010.
Comercialmente a Agence opera nas seguintes modalidades de contrato:
• Escopo fechado: tipo mais comum de contrato para projetos de desenvolvimento de
software. Neste modelo, o escopo, prazo e custo do projeto são fixos, existe pouco
espaço para mudanças e todos os requisitos são especificados antes do fechamento do
contrato.
• Banco de horas (escopo aberto): mais comum para projetos onde o escopo não pode
ser definido antes do fechamento do contrato. Neste caso, estima-se o custo do projeto
com base em um escopo inicial e os requisitos são detalhados ao longo do
desenvolvimento.
• Horas abertas: usado em projetos de manutenção onde o cliente solicita ajustes ou
implementações pontuais em um software já implantado em ambiente de produção.
• Outsourcing: alocação de profissionais na estrutura da Agence ou do Cliente. Este
tipo de contrato prevê que a gestão dos profissionais é de responsabilidade da equipe
do cliente.
12
Boa parte dos projetos da empresa são fechados no modelo de contrato de escopo
fechado, onde o prazo, custo e escopo são fixados. Este modelo permite que o cliente tenha
garantia de entrega do escopo solicitado a um custo fixo. Porém, esse modelo de contrato tem
pouca abertura para mudanças no escopo, sendo que muitas vezes é necessário negociar
alterações nos requisitos para atender a solução esperada.
Os contratos de escopo aberto têm como característica a negociação de uma franquia
de horas estimada, ou banco de horas, com base no escopo inicial do projeto informado pelo
cliente. Desta forma o escopo pode sofrer modificações ao longo do desenvolvimento nem
necessidade de re-negociação de contratos.
Segundo [Beck 1999] em contratos de escopo aberto (ou negociável) o tempo e o
custo são fixos e o nível de qualidade exigido pelo cliente deve ser obedecido. Deve-se
parecer com algo do tipo: “Vamos pagar R$ 150.000,00 por mês por uma equipe de seis
desenvolvedores pelos próximos 2 meses”. Porém, o prazo de 2 meses equivale a 1/6 do
projeto. Neste caso, um contrato curto é fechado, arriscando somente 2 meses do orçamento
total do projeto. As estimativas iniciais e um pouco de matemática dão ao cliente uma boa
visão do que será obtido nos próximos contratos.
Durante esse tempo as expectativas de cliente e fornecedor serão [Beck 1999]:
Tabela 1 - Expectativas do cliente e do fornecedor de contratos de escopo aberto
Cliente Fornecedor
Interpretar os requisitos o mais Feliz por aceitar as mudanças de
amplamente possível para obter o maior interpretação dos requisitos por parte do
valor possível do dinheiro investido. cliente.
Quer o serviço pronto o mais rápido Quer entregar no prazo. Feliz por entregar
possível. o mais número possível de
funcionalidades, sem riscos para a
qualidade.
Quer qualidade superlativa. Quer qualidade antes de qualquer coisa.
Cliente quer que os desenvolvedores Quer que a equipe tenha sucesso nesse
continuem o projeto após a primeira fase projeto já de olho nos próximos.
de 2 meses.
3.2. Projetos de Escopo Aberto na Agence

Na Agence, os projetos de escopo aberto realizados tiveram resultados distintos.
Citando dois exemplos, aqui identificados apenas por Projeto 1 e Projeto 2 por questões de
confidencialidade:
O Projeto 1 envolvia uma equipe de 3 profissionais onde seria necessário usar um
sistema de código aberto e desenvolver alguns módulos e integrações. O prazo para colocar a
primeira versão em produção era de 20 dias e envolvia o cadastro de usuários do sistema,
integração com o software de código aberto, configuração do servidor e de alguns processos
básicos.
Essa primeira fase do projeto foi bastante movimentada e os processos não puderam
ser seguidos. Porém, nos próximos 3 meses de projeto, a equipe conseguiu atender bem as
expectativas do cliente e o foi possível diminuir gradativamente o tamanho da equipe até que
todas as funcionalidades desejadas para o projeto foram entregues.
13
A avaliação do projeto foi bastante positiva, mesmo sendo necessário dar um desconto
do valor cobrado no meio do projeto devido a baixa produtividade de um profissional
envolvido.
O Projeto 2 envolvia uma equipe de 4 profissionais para desenvolvimento de um
sistema de maior complexidade, com prazo mais largo e com o escopo - mas precisamente as
regras de negócio - pouco esclarecidas no início.
Foi de fundamental importância a definição de uma arquitetura que permitisse a
customização de vários processos envolvidos no sistema permitindo que novos requisitos
fossem adicionados no projeto durante o decorrer do tempo.
No final, o resultado técnico do projeto foi bastante satisfatório, fazendo amplo uso de
práticas ágeis como desenvolvimento dirigido por testes, refatoração, integração contínua,
entre outras, garantindo alta qualidade do código-fonte. Porém o resultado gerencial não foi
bom, com vários problemas relacionados ao custo final da solução que não ficou dentro do
orçamento previsto pelo cliente.
Esses são dois casos típicos que não poderiam ser desenvolvidos na modalidade de
escopo fechado visto que o requisitos não eram claros no início e havia um desejo por parte
do cliente de incorporar mudanças nos requisitos durante o decorrer do desenvolvimento.
A menor rigidez no gerenciamento do projeto e dos requisitos causou problemas no
momento de negociar os valores pagos versus as funcionalidades desenvolvidas. Na prática,
variações na produtividade dos profissionais, ausência de um planejamento a ser seguido,
expectativas do cliente mal compreendidas e pouca clareza nos relatórios de desempenho
causaram boa parte dos problemas sofridos.
4. Processo de Desenvolvimento
O Processo de Desenvolvimento de Software da Agence, também chamado simplesmente de
AgencePDS é baseado no OpenUP/Basic e inclui algumas práticas do XP (Extreme
Programming).
Esse processo já é utilizado na Agence há 10 meses e tem funcionado bem para
projetos de escopo fechado. Para projetos de escopo aberto, foi necessário fazer algumas
adaptações para permitir menor rigidez na definição do escopo logo no início do projeto e
maior capacidade para abraçar mudanças mantendo um bom nível de controle e
gerenciamento ao longo da execução do projeto.
A seguir, essa proposta será apresentada. Daqui pra frente vamos nos referir a esse
processo simplesmente por AgencePDS EA.
4.1. Abordagem Ágil
O contrato de escopo aberto facilita bastante a questão burocrática das mudanças no projeto
entretanto, se algumas práticas não forem seguidas, é possível que haja um colapso do código-
fonte do sistema devido a falta de preparação para “abraçar” essas mudanças.
Neste ponto que as metodologias ágeis são de grande valia para aplicação de técnicas
de engenharia que diminuem drasticamente o impacto das constantes mudanças no código-
fonte.
As práticas citadas a seguir são do método XP [Teles 2004]:
• Desenvolvimento Dirigido por Testes: Os desenvolvedores escrevem testes para
cada funcionalidade antes de codificá-las. Fazendo isso, eles aprofundam o
entendimento das necessidades do cliente (o que aprimora a análise), se preocupam
com as interfaces externas dos métodos e classes antes de codificá-los (o que melhora
14
o design), sabem até onde codificar cada funcionalidade (o que ajuda a manter o
sistema simples) e passam a contar com uma massa de testes que pode ser usada a
qualquer momento para validar todo o sistema.
• Refatoring: é o ato de alterar um código sem afetar a funcionalidade que ele
implementa. É utilizado para tornar o software mais simples de ser manipulado e se
utiliza fortemente dos testes descritos anteriormente para garantir que as modificações
não interrompam o seu funcionamento.
• Código Coletivo: o sistema não é segmentado em partes, de modo que cada
desenvolvedor fique responsável por uma delas. Os desenvolvedores têm acesso a
todas as partes do código e podem alterar aquilo que julgarem importante sem a
necessidade de pedir autorização de outra pessoa, pois o código é coletivo.
• Código Padronizado: para que todos os desenvolvedores possam manipular qualquer
parte do software de forma mais rápida, a equipe estabelece padrões de codificação,
que servem também para tornar o sistema mais homogêneo e permitir que qualquer
manutenção futura seja efetuada mais rapidamente.
• Design Simples: para que o cliente possa obter feedback logo, a equipe precisa ser
ágil no desenvolvimento, o que a leva a optar pela simplicidade do design. Ao invés
de criar generalizações dentro do código, de modo a prepará-lo para possíveis
necessidades futuras, a equipe deve sempre optar por um código que seja suficiente
para atender às necessidades da funcionalidade que está implementando. Os
desenvolvedores se baseiam na premissa de que serão capazes de incorporar qualquer
necessidade futura quando e se ela surgir.
• Ritmo Sustentável: para garantir que a equipe tenha sempre o máximo de rendimento
e produza software com melhor qualidade possível, os desenvolvedores trabalhem
apenas oito horas por dia e evitem fazer horas-extras, visto que é essencial estar
descansado a cada manhã, de modo a utilizar a mente na sua plenitude ao longo do
dia.
• Integração Contínua: para assegurar que todo o sistema esteja sempre funcionando
de forma harmoniosa, a equipe pratica a integração contínua que leva os
desenvolvedores a integrarem seus códigos com o restante do sistema diversas vezes
ao dia. Cada vez que um desenvolvedor faz isso, ele executa todos os testes para
assegurar que a integração tenha ocorrido de forma satisfatória.
Além do uso das práticas do XP, o detalhamento das atividades é baseado no OpenUP/Basic.
Para a documentação do processo foi utilizada a ferramenta Eclipse Process Framework
(EPF). [Eclipse 2009b]
4.2. Modelo do Processo
O processo de desenvolvimento proposto para projetos de escopo aberto é uma adaptação do
processo de projetos de escopo fechado.
4.2.1. Estrutura Analítica do Projeto
A estrutura Estrutura Analítica do Projeto, ou EAP segue o modelo abaixo:
1. Iteração de Prospecção #1
1.1. GPR01 - Criar OS de Prospecção
1.2. GRE01 - Elicitar Requisitos
1.3. GPR02 - Estimar Custo e Prazo
15
1.4. GRE02 - Elaborar Proposta Comercial
1.5. GPR04 - Criar OS de Produção
1.6. GPR05 - Elaborar Plano do Projeto
1.7. GCO01 - Configurar Ambiente do Projeto
1.8. GPR07 - Finalizar Iteração
2. Iteração de Construção #1..N
2.1. GPR06 - Planejar Iteração
2.2. GRE01- Elicitar Requisitos
2.3. DRE01 - Construir Protótipo Funcional
2.4. DRE02 - Especificar Requisitos
2.5. PCP01 - Projetar Solução
2.6. PCP02 - Codificar Versão do Software
2.7.VAL01 - Planejar Testes
2.8. VAL02 - Testar Versão do Software
2.9. ITP01 - Implantar Versão do Software
2.10. VAL04 - Conduzir Testes de Aceitação
2.11. GPR08 - Controlar Cronograma
2.12. GRE03 - Gerenciar Mudanças
2.13. GPR07 - Finalizar Iteração
3. Iteração de Transição #1
3.1. GPR06 - Planejar Iteração
3.2.VAL04 - Conduzir Testes de Aceitação
3.3. VAL03 - Executar Testes de Performance
3.4. PCP02 - Codificar Versão do Software
3.5. ITP02 - Configurar Ambiente de Produção
3.6. ITP03 - Implantar Software em Produção
3.7. DRE03 - Realizar Treinamentos
3.8. GRP09 - Finalizar Projeto
4.2.2. Modelo de Ciclo de Vida

O modelo de ciclo de vida usado pelo AgencePDS EA é iterativo e incremental. As iterações
típicas do projeto são:
4.2.2.1. Iteração de Prospecção
É o momento do projeto onde é feita a negociação do contrato junto do cliente. Nesta iteração,
o escopo do projeto é definido, mesmo que não seja o escopo definitivo do projeto. Também
são estimados o custo e prazo, assim como é obtido o compromisso do cliente com o plano do
projeto. O ambiente de configuração do projeto é criado e todos os artefatos produzidos até o
momento são colocados sob uma linha básica.
16
Tipicamente haverá somente uma iteração de prospecção no projeto com duração
aproximada de 15 a 30 dias. A figura 2 apresenta a seqüência dos processos.
Figura 2 - Fluxo dos Processos da Iteração de Prospecção

4.2.2.2. Iteração de Construção
Devido ao fato do escopo do projeto ser aberto, não existe no AgencePDS EA a fase de
Elaboração do OpenUP/Basic [Eclipse 2006]. Neste caso, os requisitos são detalhados em
uma ou mais iterações de construção que tem duração de 15 a 45 dias dependendo do projeto.
17
Nessa iteração, todas as atividades de planejamento, especificação de requisitos,
projeto da solução, codificação, testes e implantação são realizadas. Logo na primeira semana
da iteração são definidas quais funcionalidades do software serão priorizadas e um
cronograma é montado com base nas estimativas.
18
Figura 3 - Fluxo dos Processo da Iteração de Construção
O escopo da iteração é detalhado por meio da construção de protótipos funcionais e
especificação de requisitos usando a técnica de casos de uso [Cockburn 2004]. Neste
momento o Analista de Teste planeja os casos de teste que serão executados posteriormente.
O projeto de cada funcionalidade é feita pela equipe composta por arquiteto e
desenvolvedores do projeto em conjunto com o analista de negócio para dar embasamentos
sobre questões relacionada a requisitos.
Ao término da codificação das funcionalidades, tipicamente de 3 a 7 dias antes do
término da iteração, o analista de teste realiza os testes funcionais e junto com os
desenvolvedores finaliza a integração da versão.
No decorrer de toda a iteração, o Analista de Negócio acompanha junto com a equipe
o andamento do projeto fazendo pontos de controle pelo menos duas vezes por semana para
resolver dúvidas e impedimentos.
Ao término da iteração, o Gerente de Projeto realiza testes de aceitação com os
Stakeholders e uma reunião com toda a equipe para finalizar a iteração, coletar os indicadores
e planejar a próxima iteração do projeto.
Normalmente um projeto terá de 3 a 6 iterações de produção com duração aproximada
de 15 a 45 dias. A figura 3 apresenta a seqüência dos processos.
4.2.2.3. Iteração de Transição
Nesta iteração as tarefas finais para implantação do software em ambiente de produção são
realizadas.
É nesse momento que os testes de aceitação são realizados com o usuário final do
sistema em ambiente de pré-produção. Tipicamente ajustes são solicitados e o resultam nas
últimas tarefas para produção da versão final do software. Por fim os usuários são treinados.
Os testes de performance também devem ser executados, visto que o ambiente que
simula a produção deve ser testado com o número de usuários previsto e simulando condições
de sazonalidade e recuperação no caso de falhas.
O ambiente de produção do sistema deverá ser preparado e os procedimentos de
instalação devem ser testados a fim de minimizar problemas no momento da disponibilização
do sistema.
Após a disponibilização do sistema em produção, é realizada uma reunião envolvendo
toda a equipe do projeto para avaliação do desempenho e documentação de lições aprendidas.
A iteração tem duração comum de 30 a 45 dias, podendo variar devido a dificuldades ou
dependências para configurar o ambiente de produção. A figura 4 apresenta a seqüência dos
processos.
4.2.3. Papéis
Os papéis que atuam no projeto são:
• Gerente de Projeto: é responsável pelo contato junto ao cliente, pela elicitação dos
requisitos, construção e aprovação de cronogramas, condução de testes de aceitação e
treinamento.
• Analista de Negócio: é responsável pela especificação dos requisitos da solução,
construção do protótipo e acompanhamento do cronograma junto da equipe de
desenvolvimento.
19
• Arquiteto: é responsável pelo projeto da solução técnica e atua como suporte para a
equipe de desenvolvimento.
• Analista de Teste: é responsável pelo planejamento (em conjunto com o Gerente de
Projeto), construção e execução dos testes.
• Desenvolvedor: é responsável pela codificação da solução e pelo desenvolvimento e
execução de testes unitários, de performance e carga.
• Administrador de Redes: é responsável pela configuração dos ambiente de
homologação e produção do projeto.
• Stakeholders: são os interessados pelo projeto. Geralmente esse papel é representado
pelo cliente ou usuário final.
Figura 4 - Fluxo dos Processos da Iteração de Transição

A tabela abaixo apresenta um mapeamento dos processos do AgencePDS por processo
do MPS.BR, papel e artefatos produzidos:
Tabela 2 - Processos, Papéis e Artefatos do Agence PDS EA
Processo AgencePDS Papel Artefatos

Processo MPS.BR: GPR - Gerência de Projetos
20
GPR01 - Criar OS de Gerente de Projeto OPS - OS de
Prospecção Prospecção
GPR02 - Estimar Custo e Gerente de Produção e Gerente de ES - Estimativas de
Prazo Projeto Software, RH - Registro
de Horas
GPR03 - Criar OS de Gerente de Produção OPR - OS de produção
Produção
GPR04 - Elaborar Plano Gerente de Projeto, Arquiteto, PD - Plano de
do Projeto Analista de Teste, Analista de Desenvolvimento, RH -
Negócio Registro de Horas
GPR05 - Planejar Gerente de Projeto, Arquiteto, PI - Plano da Iteração,
Iteração Analista de Teste, Analista de RH - Registro de Horas
Negócio, Stakeholders
GPR06 - Finalizar Gerente de Projeto, Arquiteto, RI - Relatório da
Iteração Analista de Teste, Analista de Iteração, RH - Registro
Negócio de Horas
GPR07 - Controlar Analista de Negócio, Gerente de PI - Plano da Iteração
Cronograma Projeto
GPR08 - Finalizar Gerente de Projeto, Arquiteto, RP - Relatório do
Projeto Analista de Teste, Analista de Projeto, RH - Registro
Negócio de Horas
Processo MPS.BR: GRE - Gerência de Requisitos
GRE01 - Elicitar Analista de Negócio, Gerente de ER - Especificação de
Requisitos Projeto Requisitos, NR - Notas
da Reunião, RH -
Registro de Horas
GRE02 - Elaborar Gerente de Projeto, Analista de PC - Proposta
Proposta Comercial Negócio, Gerente de Produção Comercial, RH -
Registro de Horas
GRE03 - Gerenciar Gerente de Projeto, Arquiteto, SM - Solicitação de
Mudanças Analista de Negócio Mudança, PI - Plano da
Iteração, RH - Registro
de Horas, ER -
Especificação de
Requisitos
Processo MPS.BR: DRE - Desenvolvimento de Requisitos
DRE01 - Construir Analista de Negócio, Gerente de PF - Protótipo
Protótipo Funcional Projeto Funcional, RH -
Registro de Horas
DRE02 - Especificar Analista de Negócio, Gerente de ER - Especificação de
Requisitos Projeto, Arquiteto Requisitos, RH -
Registro de Horas
DRE03 - Realizar Gerente de Projeto, Analista de MT - Material de
Treinamentos Negócio Treinamento
Processo MPS.BR: VAL - Validação
21
VAL01 - Planejar Testes Analista de Teste, Analista de PT - Plano de Testes,
Negócio, Gerente de Projeto RH - Registro de Horas
VAL02 - Testar Versão Analista de Teste, Analista de RT - Registro de Teste,
do Software Negócio, Desenvolvedor RH - Registro de Horas
VAL03 - Executar Testes Analista de Teste, Desenvolvedor RT - Registro de Teste,
de Performance RH - Registro de Horas
VAL04 - Conduzir Testes Gerente de Projeto, Analista de RT - Registro de Teste,
de Aceitação Negócio, Analista de Teste, RH - Registro de Horas
Stakeholders
Processo MPS.BR: PCP - Projeto e Construção do Produto
PCP01 - Projetar Arquiteto, Desenvolvedor, AS - Arquitetura de
Solução Analista de Negócio Software, RH - Registro
de Horas
PCP02 - Codificação Desenvolvedor, Arquiteto IS - Incremento de
Versão do Software Software, RH - Registro
de Horas
Processo MPS.BR: ITP - Integração do Produto
ITP01 - Implantar Versão Desenvolvedor, Arquiteto RS - Release de
do Software Software
ITP02 - Configurar Administrador de Rede AP - Ambiente de
Ambiente de Produção Produção, RH -
Registro de Horas
ITP03 - Implantar Arquiteto, Desenvolvedor RP - Release de
Software em Produção Produção, RH -
Registro de Horas
Processo MPS.BR: GCO - Gerência de Configuração
GCO01 - Configurar Administrador de Rede CV - Repositório de
Ambiente do Projeto Controle de Versão, PR
- Configuração do
Projeto no APMO
Processo MPS.BR: GQA - Garantia da Qualidade
GQA01 - Realizar Garantia da Qualidade RA - Relatório da
Auditoria Interna Auditoria
4.3. Perfil de Capacidade do Processo

O AgencePDS EA, na sua primeira versão, tem como objetivo a compatibilidade com o
MPS.BR Nível G de maturidade que inclui as áreas de processo GPR - Gerência de Projetos
e GRE - Gerência de Requisitos.
Os atributos de processo a serem atendidos são:
• AP 1.1 O processo é executado
• RAP 1. O processo atinge seus resultados definidos.
• AP 2.1 O processo é gerenciado
• RAP 2. Existe uma política organizacional estabelecida e mantida para o
processo;
22
• RAP 3. A execução do processo é planejada;
• RAP 4. A execução do processo é monitorada e ajustes são realizados;
• RAP 5. As informações e os recursos necessários para a execução do processo
são identificados e disponibilizados;
• RAP 6. As responsabilidades e a autoridade para executar o processo são
definidas, atribuídas e comunicadas;
• RAP 7. As pessoas que executam o processo são competentes em termos de
formação, treinamento e experiência;
• RAP 8. A comunicação entre as partes interessadas no processo é gerenciada de
forma a garantir o seu envolvimento;
• RAP 9. Os resultados do processo são revistos com a gerência de alto nível
para fornecer visibilidade sobre a sua situação na organização;
• RAP 10. O processo planejado para o projeto é executado.
4.4. Soluções do Processo para o MPS.BR
A seguir, as soluções propostas para atender cada resultado esperado conforme o Perfil de
Capacidade do Agence PDS EA são apresentadas. Por se tratar de um mapeamento de
processo, em alguns pontos a presença de evidência é bem nítida, em outros nem tanto. A
idéia é apresentar a relação existente entre o Agence PDS EA e os resultados esperados das
áreas de processo do MPS.BR Nível G.
Para facilitar o entendimento da solução, os modelos dos documentos ou artefatos
usados como evidências estão disponíveis nos anexos deste artigo conforme a relação abaixo:
Tabela 3 - Relação de Modelos de Documentos Anexos
Documento/Artefato Anexo
PD - Plano de Desenvolvimento Anexo A
PI - Plano da Iteração Anexo B
RI - Relatório da Iteração Anexo C
UCP - Estimativa por Pontos de Caso de Uso Anexo D
NR - Nota da Reunião Anexo E
UC - Caso de Uso Anexo F
SM - Solicitação de Mudança Anexo G
4.4.1. GPR - Gerência de Projetos

O propósito do processo Gerência de Projetos é estabelecer e manter planos que definem as
atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o
andamento do projeto que permitam a realização de correções quando houver desvios
significativos no desempenho do projeto. O propósito deste processo evolui à medida que a
organização cresce em maturidade. Assim, a partir do nível E, alguns resultados evoluem e
outros são incorporados, de forma que a gerência de projetos passe a ser realizada com base
no processo definido para o projeto e nos planos integrados. No nível B, a gerência de
projetos passa a ter um enfoque quantitativo, refletindo a alta maturidade que se espera da
organização. Novamente, alguns resultados evoluem e outros são incorporados [SOFTEX
2007b].
A seguir são apresentados os resultados esperados e a solução proposta:
23
GPR 1. O escopo do trabalho para o projeto é definido;
Descrito nos documentos PC - Proposta Comercial e PD - Plano de Desenvolvimento.
Por se tratar de um escopo aberto, o escopo deve ser re-avaliado ao término de cada iteração.
GPR 2. As tarefas e os produtos de trabalho do projeto são dimensionados utilizando
métodos apropriados;
O dimensionamento de tamanho do projeto é feito usando a técnica de Pontos por
Casos de Uso e evidenciadas no documento ES - Estimativas de Software. Ao término de cada
iteração, as estimativas são re-avaliadas.
GPR 3. O modelo e as fases do ciclo de vida do projeto são definidos;
O ciclo de vida e fases do projeto é fixado conforme modelo de contrato. Mais
detalhes estão disponíveis na seção 4.2.2 deste artigo.
GPR 4. O esforço e o custo para a execução das tarefas e dos produtos de trabalho são
estimados com base em dados históricos ou referências técnicas;
A estimativa de esforço é feita multiplicando a quantidade de pontos de casos de uso
ajustados pelo valores da tabela de produtividade conforme a tecnologia usada no projeto.
Para estimativa de custo multiplica-se as horas (esforço) de cada fase do projeto
(gerenciamento, análise e projeto, requisitos, codificação, testes e implantação) pelos
respectivos valores da tabela de preço que também considera. Os resultados são evidenciados
no documento ES - Estimativas de Software. Ao término de cada iteração, as estimativas são
re-avaliadas.
GPR 5. O orçamento e o cronograma do projeto, incluindo a definição de marcos e
pontos de controle, são estabelecidos e mantidos;
Na primeira iteração do projeto um cronograma macro do projeto é elaborado com
base no escopo inicial e evidenciado no documento PD - Plano de Desenvolvimento. O
término de cada iteração de construção representa um marco do projeto e os pontos de
controle devem ser realizados pelo menos duas vezes por semana. O cronograma detalhado de
cara iteração é evidenciado no artefato PI - Plano da Iteração.
GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de
ocorrência e prioridade de tratamento são determinados e documentados;
Na seção Riscos, do documento PD - Plano de Desenvolvimento, os riscos são
identificados e aqueles com maior probabilidade de ocorrência e impacto têm um plano de
contingência elaborado. Os riscos são re-avaliados no término de cada iteração do projeto e
evidenciados no documento PI - Plano da Iteração.
GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil e o
conhecimento necessários para executá-lo;
Na seção Organização do Projeto, do documento PD - Plano de Desenvolvimento,
todos os envolvidos do projeto e suas responsabilidades no processo e papéis no Agence PDS
EA são definidas. Na descrição do processo são especificadas as atividades e o perfil de cada
papel. A cada iteração os recursos são alocados e planejados no documento PI - Plano da
Iteração.
Na seção Recursos do Projeto, do documento PD - Plano de Desenvolvimento, os uso
dos recursos humanos, as necessidades de treinamento e de contratação são planejadas.
GPR 8. Os recursos e o ambiente de trabalho necessários para executar o projeto são
planejados;
24
Na sub-seção Aquisição de Recursos da seção Recursos do Projeto, do documento PD
- Plano de Desenvolvimento, as necessidade de aquisição são planejadas, incluindo criação de
ambientes para homologação e/ou produção e necessidades de viagens.
GPR 9. Os dados relevantes do projeto são identificados e planejados quanto à forma de
coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los,
incluindo, se pertinente, questões de privacidade e segurança;
Na seção Planejamento, do documento PD - Plano de Desenvolvimento, todos os
produtos que serão liberados durante a execução do projeto são planejados. O meio que estes
produtos serão armazenados, bem como sua confidencialidade, padronização de nomes e
controle de versão são detalhados na descrição do processo.
GPR 10. Um plano geral para a execução do projeto é estabelecido com a integração de
planos específicos;
Os documentos PD - Plano de Desenvolvimento, ES - Estimativas de Software, PI -
Plano da Iteração e RI - Relatório da Iteração contém todas as informações necessárias para a
execução do projeto. Esses documentos são revisados (ou criados) no término de cada
iteração.
GPR 11. A viabilidade de atingir as metas do projeto, considerando as restrições e os
recursos disponíveis, é avaliada. Se necessário, ajustes são realizados;
No início de cada iteração, a viabilidade do atingimento das metas do projeto é
avaliada com base no resultado da iteração anterior. Neste momento, o planejamento da
iteração considera os recursos disponíveis e faz os devidos ajustes. Durante os pontos de
controle semanais as correções necessárias para o bom andamento do projeto são feitas, e seja
caso necessário, o plano da iteração é alterado. As mudanças no escopo solicitadas pelo
cliente são registradas e avaliadas e, caso necessário, o plano da iteração é alterado para
agregar novas tarefas. Os documentos SM - Solicitação de Mudança e PI - Plano da Iteração
evidenciam estas práticas.
GPR 12. O Plano do Projeto é revisado com todos os interessados e o compromisso com
ele é obtido;
No início de cada iteração uma reunião com a equipe e com o cliente são realizadas
para aprovação e compromisso com o plano. Nessa reunião, um relatório da iteração anterior
é apresentado e as justificativas para diferenças são apresentadas e discutidas. É necessário
obter aprovação do plano da iteração pelo cliente para dar início aos trabalhos.
GPR 13. O projeto é gerenciado utilizando-se o Plano do Projeto e outros planos que
afetam o projeto e os resultados são documentados;
O documento RI - Relatório da Iteração apresenta os resultados da execução da
iteração do projeto, considerando o esforço e custo previsto versus realizado. Neste relatório,
as diferenças encontradas são justificadas, os motivos são discutidos e estratégias são
definidas para evitar recorrência.
O documento PI - Plano da Iteração apresenta o cronograma das atividades que serão
realizadas durante a iteração apresentando estimativas de horas, datas de início e término e
recursos humanos envolvidos.
GPR 14. O envolvimento das partes interessadas no projeto é gerenciado;
As partes interessadas no projeto são identificadas na seção Organização do Projeto,
do documento PD - Plano de Desenvolvimento. As responsabilidades das partes deve ser
avaliadas no término da iteração e mudanças devem ser documentadas no documento PD -
Plano de Desenvolvimento.
25
GPR 15. Revisões são realizadas em marcos do projeto e conforme estabelecido no
planejamento;
No término de cada iteração os resultados da iteração anterior são avaliados e o
planejamento da próxima é definido. Os artefatos PI - Plano da Iteração e RI - Relatório da
Iteração evidenciam esses resultados.
GPR 16. Registros de problemas identificados e o resultado da análise de questões
pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes
interessadas;
No documento RI - Relatório da Iteração todas as diferenças entre o planejamento e a
execução são identificados, justificados e discutidos com a equipe com o fim de evitar a
recorrência. Nesse momento, novos riscos podem ser incluídos na lista de riscos e outros
podem ser desconsiderados.
GPR 17. Ações para corrigir desvios em relação ao planejado e para prevenir a repetição
dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua
conclusão;
Como já mencionado no documento RI - Relatório da Iteração os problemas
identificados durante a execução da iteração são identificados e tratados. Ações para resolver
pendências devem ser consideradas no planejamento da próxima iteração e gerenciadas até
sua conclusão.
4.4.2. GPR - Gerência de Requisitos
O propósito do processo Gerência de Requisitos é gerenciar os requisitos do produto e dos
componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos
do projeto e os produtos de trabalho do projeto.
A seguir são apresentados os resultados esperados e a solução proposta:
GRE 1. Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de
requisitos, utilizando critérios objetivos;
O documento NR - Nota da Reunião contém o resumo das reuniões para discussão de
requisitos com o cliente. Todos os requisitos são documentados, usando a técnica de Casos de
Uso, no artefato ER - Especificação de Requisitos. Esses requisitos devem ser verificados
usando o CH01 - Checklist de Casos de Uso.
No início de cada iteração, é necessário obter aprovação dos requisitos por parte do
cliente. Isto é feito durante a reunião de início da iteração (ou kick off).
GRE 2. O comprometimento da equipe técnica com os requisitos aprovados é obtido;
Na reunião de início de cada iteração, os requisitos do projeto são explicados para a
equipe técnica que deve opinar e discutir.
GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é
estabelecida e mantida;
Usando a ferramenta interna de gerenciamento de projetos, todo código-fonte enviado
para o sistema de controle de versões deve possuir uma identificação do ticket que originou.
Desta forma, é possível rastrear quais requisitos estão relacionados com quais componentes
de software e vice-e-versa.
GRE 4. Revisões em planos e produtos de trabalho do projeto são realizadas visando
identificar e corrigir inconsistências em relação aos requisitos;
26
Nos últimos dias da iteração, todos os produtos de trabalho são testados e quaisquer
inconsistências são reportadas na ferramenta interna de gerenciamento de projetos.
GRE 5. Mudanças nos requisitos são gerenciadas ao longo do projeto.
As mudanças nos requisitos são solicitadas formalmente e documentadas no artefato
SM - Solicitação de Mudança. Essas solicitações são analisadas pela equipe técnica e, se for o
caso, são incluídas no cronograma do projeto. As mudanças nos requisitos são documentadas
no artefato ER - Especificação de Requisitos.
4.4. Adaptações do Processo
O processo pode ser adaptado para algumas situações típicas já identificadas para tipos
específicos de projeto:
Em projetos menores de 500 horas, geralmente não é utilizada a técnica de casos de
uso para documentação de requisitos. Nesses casos, os requisitos são documentados
agrupados por funcionalidades e as estimativas feitas usando a técnica de pontos por função
ou usando planilha interna de estimativas.
O processo VAL03 (Executar Testes de Performance) pode ser opcional quando não
está especificado no planejamento de testes do projeto que serão necessários implementar e
executar testes de performance.
O processo DRE3 (Realizar Treinamentos) é opcional quando não foi especificado no
plano de projetos que haverá necessidade de treinamento do usuário final.
Os processos ITP02 (Configurar Ambiente de Produção) e ITP03 (Implantar Software
em Produção) são opcionais para situações onde o ambiente de produção do projeto é de
inteira responsabilidade do cliente. Nesse caso, é simplesmente gerado um pacote contendo os
componentes do software e enviá-lo à equipe de suporte do cliente.
Podem existir casos de projetos onde o software será implantado em ambiente de
produção a cada término de iteração. Nesses casos, o processo ITP02 (Configurar Ambiente
de Produção) deve ser executado na primeira iteração de construção e o processo ITP03
(Implantar Software em Produção) ao término de cada iteração. Opcionalmente os processos
VAL03 (Executar Testes de Performance) e DRE3 (Realizar Treinamentos) poderão ser
executado nas iterações onde houver necessidade. Nesse tipo de projeto, a iteração de
transição não será necessária.
5. Conclusão
É sabido que Melhoria do Processo de Software é uma jornada sem fim em busca da melhoria
contínua. Este trabalho apresentou um esforço de dois meses da equipe de definição de
processos da Agence trabalhando nesse escopo. Em um futuro próximo, já é almejada a
adaptação do processo para o nível F do MPS.BR.
O processo proposto neste artigo está sob avaliação em um projeto piloto da Agence.
Ao final, os ajustes necessários serão implementados e processo será usado para novos
projetos de escopo aberto. A documentação do processo está sendo finalizada para que seja
possível realizar treinamentos com a equipe.
Este trabalho mostrou como é possível usar boas práticas de gerenciamento, em
conformidade com o nível G do MPS.BR, aliadas a boas práticas de engenharia, adotadas a
partir de métodos ágeis. Neste cenário, grandes melhorias na medição dos processos permite
alcançar uma maior previsibilidade no processo de desenvolvimento de software.
Dentre os resultados obtidos no curto prazo estão: avaliação e melhoria da precisão
das estimativas, melhoria do controle de custos, que é um fator crítico para sucesso de
27
projetos de escopo aberto e menor impacto ao implementar mudanças no projeto devido ao
aumento da qualidade dos códigos-fonte e testes. Esses resultados já puderam ser observados
no projeto piloto após dois meses de andamento.
A Agence tem grande simpatia por práticas de desenvolvimento ágil, mesmo sabendo
das limitações com relação ao gerenciamento e da necessidade de profissionais altamente
capacitados para que os métodos e práticas sejam aplicados com sucesso. Desta forma, pode-
se se beneficiar do melhor dos dois mundos, criando um sistema de gerenciamento mais
formal, em compatibilidade com modelos de qualidade e aplicando práticas de excelência em
engenharia de software proveniente dos métodos ágeis.
28
REFERÊNCIAS BIBLIOGRÁFICAS
[Agile Alliance 2009] AGILE ALLIANCE. Disponível em: <http://www.agilealliance.org>.
Consultado em 08/10/2009.
[Salviano 2006] SALVIANO, C. F. Melhoria e Avaliação de Processo de Software com o
Modelo ISO/IEC 15504-5:2006. In: Curso de Pós-Graduação “Latu-
Sensu” (Especialização) a distância: Melhoria de Processo de Software. Lavras: UFLA.
[Beck 1999] BECK, K. Extreme Programming Explained. Addison-Wesley, 1999.
[Cockburn 2004] COCKBURN, A. Escrevendo Casos de Uso Eficazes. Bookman, 2004.
[Deming 1986] Edward W. Deming, W. Edward. Out of the Crisis, Cambridge. MIT Center
for Advanced Engineering Study, 1986.
[Eclipse 2006] OpenUP/Basic. Disponível em: <http://epf.eclipse.org/wikis/openuppt/>.
[Eclipse 2009b] Eclipse Process Framework. Disponível em: <http://epf.eclipse.org>.
[Beck, Beedle, Bennekum et al. 2001] BECK, K.; BEEDLE, M.; BENNEKUM A. Manifesto
for Agile Software Development. Disponível em <http://agilemanifesto.org>.
[Larman 2007] LARMAN, C. Utilizando UML e Padrões. 3. ed. Bookman, 2007.
[Teles 2004] TELES, V. M. Extreme Programming: Aprenda como encantar seus
usuários desenvolvendo software com agilidade e alta qualidade. Novatec, 2004.
[Wikipedia 2009] WIKIPEDIA. Agile Software Development. Disponível em: http://
en.wikipedia.org/wiki/Agile_software_development. Consultado em 08/10/2009.
[Softex 2009] SOFTEX. MPS.BR - Melhoria de Processo do Software Brasileiro, Guia
Geral:2009. Disponível em: <http://www.softex.br/mpsbr/_guias/guias/
MPS.BR_Guia_Geral_2009.pdf>. Consultado em 08/10/2009.
29
ANEXOS
30
Anexo A - PD - Plano de Desenvolvimento
31
Plano de Desenvolvimento de Software
1. Objetivo
[Essa seção define o propósito deste documento, apresentando uma visão geral de todo o ciclo de
desenvolvimento do so9ware. O texto abaixo pode ser man?do ou customizado. Tamanho sugerido:
10 linhas].
A finalidade do Plano de Desenvolvimento de So9ware é reunir todas as informações necessárias ao
controle do projeto. Ele descreve a abordagem dada ao desenvolvimento do so=ware e é o plano de
nível mais alto gerado e usado pelos gerentes para coordenar o esforço de desenvolvimento.
O Plano de Desenvolvimento de So9ware é usado por estas pessoas:
• Pelo gerente de projeto, para planejar a programação do projeto e as necessidades de
recursos, e para acompanhar o progresso em relação à programação.
• Pelos membros da equipe do projeto, para compreenderem quais são suas funções, quando
elas devem ser executadas e de que outras aIvidades eles dependem.
1.1. Histórico de Modi<icações

[Para criar uma nova versão na tabela, crie sempre a primeira linha e copie (manualmente) as
informações da linha de baixo. Desta forma, a úl?ma versão sempre será exibida a par?r dos campos]
Revisão Data Autor Modificações
2. Visão Geral do Produto

2.1. Finalidade, Escopo e Objetivos do Projeto
[Uma breve descrição da finalidade e dos obje?vos deste projeto e uma breve descrição dos produtos
que se espera que o projeto libere. Especifique:
• Leis, decretos e normas que regem o negócio;
• O número do contrato (caso exista);
• Uma breve descrição do cliente;
• Referenciar o documento que detalha o escopo do projeto: Documento de Visão ou
Documento de Requisitos
Tamanho sugerido: 10 linhas]
2.2. Suposições e Restrições

[Uma lista das suposições em que este plano se baseia e de quaisquer restrições como, por exemplo,
de orçamento, equipe, equipamento e programação, que se aplicam ao projeto. Tamanho sugerido: 6
linhas]
2.3. Evolução do Plano de Desenvolvimento de Software

[Os critérios para a revisão programada e a republicação deste plano. Tamanho sugerido: 6 linhas]
32
3. Organização do Projeto
3.1. Interfaces Externas
[Descreva como o projeto se relaciona com grupos externos. Para cada grupo externo, iden?fique os
nomes de contato internos e externos. Isso deverá incluir responsabilidades relacionadas à
implantação e à aceitação do produto. A tabela abaixo pode ser u?lizada como exemplo:]
En=dade Contato externo Contato interno Responsabilidades
3.2. Papéis e Responsabilidades

[Iden?fique as unidades organizacionais do projeto que serão responsáveis por cada uma das
disciplinas, detalhamentos do fluxo de trabalho e processos de suporte. O texto abaixo é fornecido
como exemplo. A tabela abaixo pode ser u?lizada como exemplo:]
Pessoa Papel no PDS
[DICA: Para cada papel que a pessoa vai atuar, coloque um link para o site do PDS-‐DígithoBrasil que
detalha todas as a?vidades que deverão ser executadas. Uma pessoa pode atuar em mais de um
papel, e também pode atuar de forma em menor proporção em alguns papéis]
4. Planejamento
4.1. Estimativas do Projeto
[Forneça informações consolidadas sobre as es?ma?vas, e os pontos e circunstâncias do projeto em
que serão feitas novas es?ma?vas. Descreva qual o método e critérios para o cálculo das
es?ma?vas.]
4.2. Planejamento dos Testes

[Liste os obje?vos a serem a?ngidos para cada uma das iterações:]
Versão Período Funcionalidades
4.3. Produtos Liberados do Projeto

[Uma lista dos artefatos a serem criados e entregues ao cliente durante o projeto, incluindo datas-‐
alvo de liberação. Os produtos listados são especificados no contrato de fornecimento. A tabela
abaixo pode ser u?lizada como exemplo:]
Iteração Versão Data-‐alvo
4.4. Recursos do Projeto

[Neste local são descritas as necessidades de so9ware, hardware e recursos humanos para
viabilização do produto]
4.4.1. Alocação de Equipe

[Iden?ficar o número e o ?po de profissionais requeridos, incluindo formações especiais, experiências,
agendados por fase ou iteração do produto. A tabela abaixo pode ser usada como exemplo:]
33
Qtde de Horas Semanais por
Recurso Papel Iteração
#1 #2 #3 #4 #N
4.4.2. Aquisição de Recursos

[Descrever o procedimento de aquisição e procura de produtos e ferramentas necessários ao
desenvolvimento do projeto, caso necessário. Descreva também necessidades de viagens ou
contratações de profissionais. Tamanho sugerido: 10 linhas]
4.4.3. Treinamento
[Listar as necessidades especiais de capacitação requeridas para a equipe do projeto, apresentando
as datas previstas para término dos treinamentos, caso necessário. Tamanho sugerido: 10 linhas]
5. Riscos
5.1. Lista de Riscos
Risco Prioridade Probabilidade Impacto Magnitude
[nome breve do risco] [cri?ca, alta, [alta, media, [alto, médio, [probabilidade x
media, baixa] baixa] baixo] impacto onde
alta = 15, média
= 10, baixa = 5]
5.2. Plano de Contingência

[O plano de con?ngência deve ser feito para os riscos com magnitude maior ou igual a 20.]
5.2.1. <Risco>
[Descreva o que está sendo feito ou será feito no projeto para reduzir o impacto do risco. Planeje as
ações que serão executadas se o risco realmente se materializar: solução alterna?va, redução de
funcionalidades, etc.
Repita essa seção para todos os riscos que serão tratados.]
34
Anexo B - PI - Plano da Iteração
35
Plano da Iteração
6. Objetivo
10 linhas].
A finalidade do Plano da Iteração é organizar todas as informações necessárias de planejamento e
controle da iteração.
O Plano da Iteração é usado por estas pessoas:

7. Escopo
[Listar os casos de uso ou funcionalidades que serão desenvolvidas na iteração e a es?ma?va de
horas para cada.]
Caso de Uso/Tarefa/Funcionalidade Es=ma=va
8. Cronograma
# Descrição Início Termino Responsável Dep.
[Caso haja o gráfico de gani, cite-‐o como referencia]
9. Equipe
[Iden?ficar o número e o ?po de profissionais requeridos, incluindo formações especiais, experiências,
agendados por fase ou iteração do produto. A tabela abaixo pode ser usada como exemplo:]
Qtde de Horas Semanais
Recurso Papel
1 2 3 4 #N
10. Riscos
10.1. Lista de Riscos
Risco Prioridade Probabilidade Impacto Magnitude
36
[nome breve do risco] [cri?ca, alta, [alta, media, [alto, médio, [probabilidade x
media, baixa] baixa] baixo] impacto onde
alta = 15, média
= 10, baixa = 5]
10.2. Plano de Contingência

[O plano de con?ngência deve ser feito para os riscos com magnitude maior ou igual a 20.]
10.3. <Risco>
[Descreva o que está sendo feito ou será feito no projeto para reduzir o impacto do risco. Planeje as
ações que serão executadas se o risco realmente se materializar: solução alterna?va, redução de
funcionalidades, etc.
Repita essa seção para todos os riscos que serão tratados.]
37
Anexo C - RI - Relatório da Iteração
38
Relatório da Iteração
11. Objetivo
10 linhas].
A finalidade do Relatório da Iteração é avaliar os resultados conforme o plano para a execução da
iteração.
O Relatório da Iteração é usado por estas pessoas:

12. Escopo Realizado

[Listar os casos de uso ou funcionalidades que serão desenvolvidas na iteração e a es?ma?va de
horas para cada.]
Caso de Uso/Tarefa/Funcionalidade Previsto Realizado
13. Problemas
[Apontar os problemas ocorridos na execução da iteração. Obrigatoriamente é necessário analisar
cada caso de uso que tenha extrapolado a es?ma?va.]
# Problema Causa Solução
14. Análise de Custo

[Apontar o uso planejado e realizado de todos os recursos do projeto Apresente um total no final.]
Recurso Uso Uso Real Diferença
Es=mado
Total
39
Anexo D - UCP - Estimativa por Pontos de Caso de Uso
40
Resumo das Estimativas
Total de UCP não Ajustados (UUCP) 55
Fator de Complexidade Técnica (TCF) 0,975
Fator de Complexidade Ambiental (ECF) 0,935
Total de UCP (UUCP * ECF * TCF) 50
Horas por UCP 12
Esforço Total 602
Custo Total R$510,00
Divisão por Fases % fase horas valor/hora

Gerenciamento 10% 60 R$90,00
Requisitos 15% 90 R$90,00
Análise e Projeto 15% 90 R$90,00
Codificação 45% 271 R$60,00
Testes 10% 60 R$60,00
Implantação 5% 30 R$120,00
100% 602 R$85,00
Lista de Casos de Uso

Casos de Uso Complexidade
UUCP
UC01 Baixa 5
UC02 Média 10
UC04 Baixa 5
UC05 Baixa 5
UC06 Baixa 5
UC07 Baixa 5
UC08 Baixa 5
UC09 Alta 15
…
Total de UUCP 55
41
Fator de Complexidade Técnica
Fator Peso Valor
TCF01 Sistema Distribuído 2 2
TCF02 Tempo de Resposta 1 4
TCF03 Eficiência do Usuário Final 1 3
TCF04 Complexidade do Processamento Interno 1 2
TCF05 Código Re-utilizável 1 3
TCF06 Faclidade de Instalação 0,5 2
TCF07 Facilidade de Uso 0,5 5
TCF08 Portabilidade 2 2
TCF09 Manutenibilidade 1 4
TCF10 Concorrência 1 3
TCF11 Requisitos Especiais de Segurança 1 2
TCF12 Provê Acesso à Terceiros 1 3
TCF13 Facilidades de Treinamento 1 2
37,5
TCF - Fatores de Complexidade Técnica

TCF não Ajustado (UTV) 37,5
TCF Fator de Peso (TWF) 0,01
TCF Constante (TC) 0,6
TCF = TC + (TWF * UTV) 0,975
Fator de Complexidade Ambiental

Fator Peso Valor
ECF01 Familiaridade com o Processo da Empresa 1,5 4
ECF02 Experiência com a Aplicação 0,5 3
ECF03 Experiência com Orientação à Objetos 1 3
ECF04 Experiência do Líder do Projeto 0,5 4
ECF05 Motivação 1 4
ECF06 Requisitos Estáveis 2 1
ECF07 Colaboradores em Tempo Parcial -1 0
ECF08 Dificuldade com a Linguagem de Programação -1 3
15,5
ECF - Fatores de Complexidade Ambiental

ECF não Ajustado (UEV) 15,5
ECF Fator de Peso (EWF) -0,03
ECF Constante (EC) 1,4
ECF = EC + (EWF * UEV) 0,935
42
Anexo E - NR - Nota da Reunião
43
Nota da Reunião
15. Identi<icação
Data: Horário:
Local: Registrado por:
Par=cipantes:
Obje=vo:
16. Pontos Discutidos

[descrever os pontos discu?dos em reunião]
16.1. Ponto 1
...
16.2. Ponto N
...
17. Pendências
[Apontar os problemas ocorridos na execução da iteração. Obrigatoriamente é necessário analisar
cada caso de uso que tenha extrapolado a es?ma?va.]
# Pendências Responsável Data Limite
44
Anexo F - UC - Caso de Uso
45
UC## - Identi<icação do Caso de Uso
18. Descrição
[Breve descrição do caso de uso. Tamanho recomendado: 2 a 5 linhas].
18.1. Escopo
[Nome do sistema, módulo, departamento, componente ao qual o caso de uso se refere. Indique se
trata-‐se de um caso de uso de negócio ou sistema e se é caixa branca ou caixa preta]
18.2. Nível
[obje?vo do usuário, subfunção, resumo]
18.3. Ator Primário

[nome do ator primário]
18.4. Atores Secundários

[outros atores que realizam o caso de uso]
18.5. Stakeholders e Interesses

[Quem se importa com o caso de uso e o que desejam]
19. Condições
19.1. Acionador
[Evento que faz o caso de uso começar]
19.2. Pré-condições
[Anuncia o que o sistema garan?rá que é verdadeiro antes de permi?r o início do caso de uso.]
19.3. Garantias Mínimas

[São as menores promessas que o sistema faz aos stakeholders, par?cularmente quando o obje?vo do
ator primário não pode ser alcançado.]
19.4. Garantias de Sucesso

[Estabelece quais interesses dos stakeholders são sa?sfeitos depois de uma conclusão bem sucedida
do caso de uso, ou ao término de um cenário de sucesso principal ou ao término de m caminho de
sucesso alterna?vo;]
20. Cenário de Sucesso Principal

[O cenário de sucesso principal e todas as extensões são acomodadas dentro da estrutura:
• Uma condição sob a qual o cenário é executado (pré-‐condição + acionador);
• Um obje?vo a alcançar;
• Um conjunto de passos de ação;
• Uma condição de fim;
• Um possível conjunto de extensões escritas como fragmentos de cenários;
Todo cenário é escrito como uma sequência de ações dos diversos atores para alcançar seu obje?vo;
• Um cenário deve descrever:
46
• Uma interação entre dois atores;
• Um passo de validação para proteger um interesse de um stakeholder;
• Uma mudança interna para sa?sfazer um interesse de um stakeholder;]
21. Extensões
[Casos de uso devem conter todos os cenários, tanto de sucesso como de falha. Poderíamos descrever
cada cenário individualmente, porém, isso é um pesadelo para manutenção. Uma boa maneira é
organizar o texto do cenário principal de sucesso com uma sequência simples até a conclusão. E então
escrever um cenário de extensão para cada ponto de desvio. Extensões estão onde os mais
interessantes requisitos residem.]
22. Requisitos
[Descrever ou referenciar requisitos aplicáveis ao caso de uso como por exemplo:
• Regras de Validação;
• Conjunto de dados u?lizados;
• Regras de negócio aplicáveis;
• Requisitos não-‐funcionais;
]
47
Anexo G - SM - Solicitação de Mudança
48
Solicitação de Mudança
23. Descrição
[Descrição detalhada da solicitação, incluindo prioridade, impacto para o negócio do cliente,
expecta?va de prazo, etc.. Preferencialmente inclua printscreen de telas, arquivos gerados, planilhas
de exemplo, protó?pos das alterações e toda e qualquer informação que possa ser ú?l na análise.]
24. Análise
24.1. Impacto
[Descreva o impacto que a mudança causa no sistema, que casos de uso/funcionalidades ela afeta,
considerações sobre dados, impacto em outros sistemas/casos de uso/funcionalidades.]
24.2. Plano de Ação

[O que deve ser feito para que a mudança seja implementada, qual es?ma?va de esforço para
desenvolvê-‐la]
49

TCC SauloArruda

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

TCC SauloArruda

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSIDADE FEDERAL DE

GERENCIANDO PROJETOS DE ESCOPO

SAULO ARRUDA COELHO

GERENCIANDO PROJETOS DE ESCOPO

Trabalho de Conclusão apresentada(o) ao Departamento

GERENCIANDO PROJETOS DE ESCOPO ABERTO:

Trabalho de Conclusão apresentada(o) ao Departamento

¹Departamento de Ciência da Computação - Universidade Federal de

Resumo. Este artigo propõe um modelo de processo para gerenciamento de

3.2. Projetos de Escopo Aberto na Agence

4.2.2. Modelo de Ciclo de Vida

Figura 2 - Fluxo dos Processos da Iteração de Prospecção

Figura 4 - Fluxo dos Processos da Iteração de Transição

Processo AgencePDS Papel Artefatos

4.3. Perfil de Capacidade do Processo

4.4.1. GPR - Gerência de Projetos

1.1. Histórico de Modi<icações

2. Visão Geral do Produto

2.2. Suposições e Restrições

2.3. Evolução do Plano de Desenvolvimento de Software

3.2. Papéis e Responsabilidades

4.2. Planejamento dos Testes

4.3. Produtos Liberados do Projeto

4.4. Recursos do Projeto

4.4.1. Alocação de Equipe

4.4.2. Aquisição de Recursos

5.2. Plano de Contingência

6.1. Histórico de Modi<icações

[Caso haja o gráﬁco de gani, cite-­‐o como referencia]

10.2. Plano de Contingência

11.1. Histórico de Modi<icações

12. Escopo Realizado

14. Análise de Custo

Divisão por Fases % fase horas valor/hora

Lista de Casos de Uso

TCF - Fatores de Complexidade Técnica

Fator de Complexidade Ambiental

ECF - Fatores de Complexidade Ambiental

16. Pontos Discutidos

18.3. Ator Primário

18.4. Atores Secundários

18.5. Stakeholders e Interesses

19.3. Garantias Mínimas

19.4. Garantias de Sucesso

20. Cenário de Sucesso Principal

24.2. Plano de Ação

S-ar putea să vă placă și

[Caso haja o gráﬁco de gani, cite-‐o como referencia]