Академический Документы
Профессиональный Документы
Культура Документы
LAVRAS
LAVRAS
MINAS GERAIS - BRASIL
2009
SAULO ARRUDA COELHO
Orientador
Prof. Geovane Nogueira Lima
LAVRAS
MINAS GERAIS - BRASIL
2009
SAULO ARRUDA COELHO
Prof. ________________
Prof. ________________
Prof. ________________
(Orientador)
LAVRAS
MINAS GERAIS - BRASIL
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¹
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.
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
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.
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.
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
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
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/>.
Consultado em 08/10/2009.
[Eclipse 2009b] Eclipse Process Framework. Disponível em: <http://epf.eclipse.org>.
Consultado em 08/10/2009.
[Beck, Beedle, Bennekum et al. 2001] BECK, K.; BEEDLE, M.; BENNEKUM A. Manifesto
for Agile Software Development. Disponível em <http://agilemanifesto.org>.
Consultado em 08/10/2009.
[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.
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
[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.]
33
Qtde
de
Horas
Semanais
por
Recurso Papel Iteração
#1 #2 #3 #4 #N
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.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
[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
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:
• 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.
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.
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.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
[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
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:
• 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.
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
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
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
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.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]
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.]
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.]
49