TCC-SauloArruda

UNIVERSIDADE FEDERAL DE LAVRAS

GERENCIANDO PROJETOS DE ESCOPO ABERTO: UMA ABORDAGEM ÁGIL

SAULO ARRUDA COELHO

LAVRASMINAS GERAIS - BRASIL

2009

SAULO ARRUDA COELHO


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.

OrientadorProf. Geovane Nogueira Lima


2009

SAULO ARRUDA COELHO


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)


2009

AGRADECIMENTOSPrimeiramente 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

[email protected]. 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çãoA 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 RelacionadosA seguir, são apresentados alguns conceitos amplamente citados neste artigo.

2.1. Desenvolvimento ÁgilEm 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

mailto:[email protected]?subject=

mailto:[email protected]?subject=

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.BRO 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ção3.1. A EmpresaA 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 FornecedorInterpretar os requisitos o mais amplamente possível para obter o maior valor possível do dinheiro investido.

Feliz por aceitar as mudanças de interpretação dos requisitos por parte do cliente.

Quer o serviço pronto o mais rápido possível.

Quer entregar no prazo. Feliz por entregar 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 continuem o projeto após a primeira fase de 2 meses.

Quer que a equipe tenha sucesso nesse projeto já de olho nos próximos.

3.2. Projetos de Escopo Aberto na AgenceNa 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 DesenvolvimentoO 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 ÁgilO 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 ProcessoO 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 ProjetoA estrutura Estrutura Analítica do Projeto, ou EAP segue o modelo abaixo:

1. Iteração de Prospecção #11.1. GPR01 - Criar OS de Prospecção1.2. GRE01 - Elicitar Requisitos1.3. GPR02 - Estimar Custo e Prazo

15

1.4. GRE02 - Elaborar Proposta Comercial1.5. GPR04 - Criar OS de Produção1.6. GPR05 - Elaborar Plano do Projeto 1.7. GCO01 - Configurar Ambiente do Projeto1.8. GPR07 - Finalizar Iteração

2. Iteração de Construção #1..N2.1. GPR06 - Planejar Iteração2.2. GRE01- Elicitar Requisitos2.3. DRE01 - Construir Protótipo Funcional2.4. DRE02 - Especificar Requisitos2.5. PCP01 - Projetar Solução2.6. PCP02 - Codificar Versão do Software2.7.VAL01 - Planejar Testes2.8. VAL02 - Testar Versão do Software2.9. ITP01 - Implantar Versão do Software2.10. VAL04 - Conduzir Testes de Aceitação2.11. GPR08 - Controlar Cronograma2.12. GRE03 - Gerenciar Mudanças2.13. GPR07 - Finalizar Iteração

3. Iteração de Transição #13.1. GPR06 - Planejar Iteração3.2.VAL04 - Conduzir Testes de Aceitação3.3. VAL03 - Executar Testes de Performance3.4. PCP02 - Codificar Versão do Software3.5. ITP02 - Configurar Ambiente de Produção3.6. ITP03 - Implantar Software em Produção3.7. DRE03 - Realizar Treinamentos 3.8. GRP09 - Finalizar Projeto

4.2.2. Modelo de Ciclo de VidaO 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éisOs 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 ArtefatosProcesso MPS.BR: GPR - Gerência de ProjetosProcesso MPS.BR: GPR - Gerência de ProjetosProcesso MPS.BR: GPR - Gerência de Projetos

20

GPR01 - Criar OS de Prospecção

Gerente de Projeto OPS - OS de Prospecção

GPR02 - Estimar Custo e Prazo

Gerente de Produção e Gerente de Projeto

ES - Estimativas de Software, RH - Registro de Horas

GPR03 - Criar OS de Produção

Gerente de Produção OPR - OS de produção

GPR04 - Elaborar Plano do Projeto

Gerente de Projeto, Arquiteto, Analista de Teste, Analista de Negócio

PD - Plano de Desenvolvimento, RH - Registro de Horas

GPR05 - Planejar Iteração

Gerente de Projeto, Arquiteto, Analista de Teste, Analista de Negócio, Stakeholders

PI - Plano da Iteração, RH - Registro de Horas

GPR06 - Finalizar Iteração


RI - Relatório da Iteração, RH - Registro de Horas

GPR07 - Controlar Cronograma

Analista de Negócio, Gerente de Projeto

PI - Plano da Iteração

GPR08 - Finalizar Projeto


RP - Relatório do Projeto, RH - Registro de Horas

Processo MPS.BR: GRE - Gerência de RequisitosProcesso MPS.BR: GRE - Gerência de RequisitosProcesso MPS.BR: GRE - Gerência de RequisitosGRE01 - Elicitar Requisitos


ER - Especificação de Requisitos, NR - Notas da Reunião, RH - Registro de Horas

GRE02 - Elaborar Proposta Comercial

Gerente de Projeto, Analista de Negócio, Gerente de Produção

PC - Proposta Comercial, RH - Registro de Horas

GRE03 - Gerenciar Mudanças

Gerente de Projeto, Arquiteto, Analista de Negócio

SM - Solicitação de Mudança, PI - Plano da Iteração, RH - Registro de Horas, ER - Especificação de Requisitos

Processo MPS.BR: DRE - Desenvolvimento de RequisitosProcesso MPS.BR: DRE - Desenvolvimento de RequisitosProcesso MPS.BR: DRE - Desenvolvimento de RequisitosDRE01 - Construir Protótipo Funcional


PF - Protótipo Funcional, RH - Registro de Horas

DRE02 - Especificar Requisitos

Analista de Negócio, Gerente de Projeto, Arquiteto

ER - Especificação de Requisitos, RH - Registro de Horas

DRE03 - Realizar Treinamentos

Gerente de Projeto, Analista de Negócio

MT - Material de Treinamento

Processo MPS.BR: VAL - ValidaçãoProcesso MPS.BR: VAL - ValidaçãoProcesso MPS.BR: VAL - Validação

21

VAL01 - Planejar Testes Analista de Teste, Analista de Negócio, Gerente de Projeto

PT - Plano de Testes, RH - Registro de Horas

VAL02 - Testar Versão do Software

Analista de Teste, Analista de Negócio, Desenvolvedor

RT - Registro de Teste, RH - Registro de Horas

VAL03 - Executar Testes de Performance

Analista de Teste, Desenvolvedor RT - Registro de Teste, RH - Registro de Horas

VAL04 - Conduzir Testes de Aceitação

Gerente de Projeto, Analista de Negócio, Analista de Teste, Stakeholders

RT - Registro de Teste, RH - Registro de Horas

Processo MPS.BR: PCP - Projeto e Construção do ProdutoProcesso MPS.BR: PCP - Projeto e Construção do ProdutoProcesso MPS.BR: PCP - Projeto e Construção do ProdutoPCP01 - Projetar Solução

Arquiteto, Desenvolvedor, Analista de Negócio

AS - Arquitetura de Software, RH - Registro de Horas

PCP02 - Codificação Versão do Software

Desenvolvedor, Arquiteto IS - Incremento de Software, RH - Registro de Horas

Processo MPS.BR: ITP - Integração do ProdutoProcesso MPS.BR: ITP - Integração do ProdutoProcesso MPS.BR: ITP - Integração do ProdutoITP01 - Implantar Versão do Software

Desenvolvedor, Arquiteto RS - Release de Software

ITP02 - Configurar Ambiente de Produção

Administrador de Rede AP - Ambiente de Produção, RH - Registro de Horas

ITP03 - Implantar Software em Produção

Arquiteto, Desenvolvedor RP - Release de Produção, RH - Registro de Horas

Processo MPS.BR: GCO - Gerência de ConfiguraçãoProcesso MPS.BR: GCO - Gerência de ConfiguraçãoProcesso MPS.BR: GCO - Gerência de ConfiguraçãoGCO01 - Configurar Ambiente do Projeto

Administrador de Rede CV - Repositório de Controle de Versão, PR - Configuração do Projeto no APMO

Processo MPS.BR: GQA - Garantia da QualidadeProcesso MPS.BR: GQA - Garantia da QualidadeProcesso MPS.BR: GQA - Garantia da QualidadeGQA01 - Realizar Auditoria Interna

Garantia da Qualidade RA - Relatório da Auditoria

4.3. Perfil de Capacidade do ProcessoO 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.BRA 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 API - Plano da Iteração Anexo BRI - Relatório da Iteração Anexo CUCP - Estimativa por Pontos de Caso de Uso Anexo DNR - Nota da Reunião Anexo EUC - Caso de Uso Anexo FSM - Solicitação de Mudança Anexo G

4.4.1. GPR - Gerência de ProjetosO 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 RequisitosO 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 ProcessoO 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

http://www.agilealliance.org

http://www.agilealliance.org

http://epf.eclipse.org/wikis/openuppt/

http://epf.eclipse.org/wikis/openuppt/

http://epf.eclipse.org

http://epf.eclipse.org

http://agilemanifesto.org

http://agilemanifesto.org

http://en.wikipedia.org/wiki/Agile_software_development




http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2009.pdf




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

Recurso PapelQtde de Horas Semanais por IteraçãoQtde de Horas Semanais por IteraçãoQtde de Horas Semanais por IteraçãoQtde de Horas Semanais por IteraçãoQtde de Horas Semanais por IteraçãoRecurso Papel#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, media, baixa]

[alta, media, baixa]

[alto, médio, baixo]

[probabilidade x 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


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:]

Recurso PapelQtde de Horas SemanaisQtde de Horas SemanaisQtde de Horas SemanaisQtde de Horas SemanaisQtde de Horas Semanais

Recurso Papel1 2 3 4 #N

10. Riscos

10.1. Lista de Riscos

Risco Prioridade Probabilidade Impacto Magnitude

36

[nome breve do risco] [cri?ca, alta, media, baixa]

[alta, media, baixa]

[alto, médio, baixo]

[probabilidade x 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


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 Es=mado

Uso Real Diferença

Total

39

Anexo D - UCP - Estimativa por Pontos de Caso de Uso

40

Resumo das EstimativasResumo das EstimativasResumo das EstimativasResumo das Estimativas

Total de UCP não Ajustados (UUCP) 55Fator de Complexidade Técnica (TCF) 0,975Fator de Complexidade Ambiental (ECF) 0,935Total de UCP (UUCP * ECF * TCF) 50Horas por UCP 12Esforço Total 602Custo Total R$510,00

Divisão por Fases % fase horas valor/horaGerenciamento 10% 60 R$90,00Requisitos 15% 90 R$90,00Análise e Projeto 15% 90 R$90,00Codificação 45% 271 R$60,00Testes 10% 60 R$60,00Implantação 5% 30 R$120,00

100% 602 R$85,00

Lista de Casos de UsoLista de Casos de UsoLista de Casos de Uso

Casos de Uso ComplexidadeUUCPUC01 Baixa 5UC02 Média 10UC04 Baixa 5UC05 Baixa 5UC06 Baixa 5UC07 Baixa 5UC08 Baixa 5UC09 Alta 15…Total de UUCPTotal de UUCP 55

41

Fator de Complexidade TécnicaFator de Complexidade TécnicaFator de Complexidade TécnicaFator de Complexidade Técnica

FatorFator Peso ValorTCF01 Sistema Distribuído 2 2TCF02 Tempo de Resposta 1 4TCF03 Eficiência do Usuário Final 1 3TCF04 Complexidade do Processamento Interno 1 2TCF05 Código Re-utilizável 1 3TCF06 Faclidade de Instalação 0,5 2TCF07 Facilidade de Uso 0,5 5TCF08 Portabilidade 2 2TCF09 Manutenibilidade 1 4TCF10 Concorrência 1 3TCF11 Requisitos Especiais de Segurança 1 2TCF12 Provê Acesso à Terceiros 1 3TCF13 Facilidades de Treinamento 1 2

37,5

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

Fator de Complexidade AmbientalFator de Complexidade AmbientalFator de Complexidade AmbientalFator de Complexidade Ambiental

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

15,5

ECF - Fatores de Complexidade AmbientalECF - Fatores de Complexidade AmbientalECF não Ajustado (UEV) 15,5ECF Fator de Peso (EWF) -0,03ECF Constante (EC) 1,4ECF = 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

Documents

Transcript of TCC-SauloArruda