Tempo

Ao chegar a este ponto do empreendimento, o gerente do projeto terá em mãos todos os requisitos detalhados e todas as atividades necessárias com as respectivas estimativas de tempo para implementar o módulo em pauta. Basta então decidir quais serão os responsáveis por cada atividade e detalhar o cronograma no Plano de Projeto. Toda a equipe deve receber a nova versão do cronograma. Fica a cargo do gerente do projeto controlar e cobrar o cumprimento dos prazos estimados.

4.10.5 Implementação (repetido a cada ciclo)

4.10.5.1 Implementar programa(s) com terceiros (opcional) 4.10.5.1.1 Encaminhar documentação:

Os seguintes documentos devem ser enviados à empresa contratada: Contrato de Requisitos, Casos de Uso detalhados, Modelo de Objetos e Diagrama de Implementação. Opcionalmente, deve ser enviado também o Modelo de Dados Relacional. A entrega da documentação deve ser devidamente protocolada para minimizar o risco de problemas de comunicação e conseqüentes atrasos ao projeto. Fica a cargo do gerente de projeto controlar e cobrar o cumprimento dos prazos acordados.

4.10.5.1.2 Receber programa codificado:

A recepção dos programas codificados deve ser de responsabilidade do analista designado. O processo deve ser devidamente protocolado e a comunicação correspondente arquivada para fins de auditoria, caso necessária posteriormente.

4.10.5.1.3 Realizar testes de unidade:

Os testes, conduzidos pelo analista designado, devem ser automatizados até onde possível para minimizar a possibilidade de erros humanos tanto na concepção do programa quanto na verificação em si. Os critérios de aceitação do produto, conforme descritos no Plano de Projeto, devem ser considerados aqui. Caso uma não conformidade seja percebida, o programa deve ser devolvido de imediato de forma que a correção seja realizada pela empresa parceira. Uma comunicação informando as causas da devolução deve ser devidamente protocolada com cópia ao gerente do projeto, que controlará e cobrará a correção. Uma vez recebida a encomenda sem problemas, uma comunicação protocolada deve ser enviada à parceira com cópia para o gerente do projeto, indicando a aceitação do produto entregue.

4.10.5.2 Implementar programa(s) com gerador de código: Estas atividades são particulares a cada tecnologia adotada.

4.10.5.3 Implementar programa(s) com gerador de telas: Estas atividades são particulares a cada tecnologia adotada.

4.10.5.4 Entregar módulo

4.10.5.4.1 Realizar testes integrados:

Os testes, conduzidos pelo analista designado, devem ser automatizados até onde possível para minimizar a possibilidade de erros humanos tanto na concepção do programa quanto na verificação em si. Os critérios de aceitação do produto, conforme descritos no Plano de Projeto, devem ser considerados aqui. Os testes integrados devem ser baseados nos Diagramas de Implementação, concebidos na fase de Requisitos.

4.10.5.4.2 Aprovar junto ao cliente:

Esta atividade é fundamental em cada iteração e para o sucesso do projeto. Apesar do cliente estar participando desde o início do processo, somente aqui é que ele verá um módulo do software completamente funcional e integrado. O gerente do projeto

deve promover uma reunião que funcionará como um marco, pois a aceitação (ou não) do cliente quanto a entrega parcial ou do produto completo é que determinará a continuidade ou encerramento do projeto. O aceite ou pedidos de mudança devem ser devidamente documentados e registrados para consulta posterior a qualquer momento. Os pedidos de mudança devem refletir nos requisitos (Contrato de Requisitos, Casos de Uso, Diagramas de Implementação e Modelo de Dados) e os documentos alterados devem sofrer nova aprovação, conforme os mesmos critérios citados em cada caso. Preferencialmente, as versões destes documentos devem ser arquivadas a cada nova versão para fins de registro histórico.

4.10.5.4.3 Implantar em produção:

A versão a ser liberada deve ser registrada no ambiente de produção do cliente, utilizando a ferramenta adotada na instalação1, de modo que ele possa utilizá-la em suas atividades diárias e, caso necessário, auditada futuramente.

4.10.5.4.4 Treinar equipe do cliente:

O treinamento é pré-requisito para que o produto entregue seja assimilado e efetivamente utilizado pelo cliente e sua equipe. Novos pedidos de funcionalidades podem surgir daí, visto que o uso também representa uma oportunidade adicional para o cliente perceber omissões ou possibilidades de melhoria. O gerente de projeto deve receber os pedidos de mudança e decidir se eles podem ser trabalhados nas próximas iterações ou se comprometem seriamente o que foi contratado para este projeto ao se considerar custo e tempo. No segundo caso, um novo projeto precisará ser aprovado, iniciado e conduzido para o atendimento ao cliente. O cliente deve ser devidamente comunicado da decisão tomada.

1 O CVS é uma ferramenta livre e gratuita bastante utilizada no momento para este fim. O Concurrent Version System (Sistema de Versões Concorrentes) é um sistema de controle de versão que permite que se trabalhe com diversas versões de arquivos organizados em um diretório e localizados local ou remotamente, mantendo-se suas versões antigas e os logs de quem e quando manipulou os arquivos. Fonte: WIKIPEDIA (2006).

4.10.6 Controle (repetido a cada ciclo) 4.10.6.1 Entregar formalmente:

Comunicação formal realizada pelo gerente do projeto às partes interessadas, marco da entrega do módulo desenvolvido, testado e entregue durante a iteração que está próxima ao seu final.

4.10.6.2 Realizar reunião de acompanhamento e controle:

Toda a equipe deve ser reunida pelo gerente do projeto que deve captar todos os dados do projeto disponíveis no momento. Avaliação da composição da equipe, cumprimento dos prazos, qualidade dos módulos entregues até o momento, qualidade do trabalho realizado por parceiros, custos do projeto, satisfação pontual do cliente e controle dos riscos identificados. A percepção do andamento do projeto deve ser apresentada à equipe com transparência, para minimizar a possibilidade de problemas que venham a prejudicar o moral dos profissionais envolvidos, caso o projeto enfrente alguma crise ou ameaça de interrupção. Todos devem ter a oportunidade de emitir suas percepções e sugestões.

4.10.6.3 Apurar resultados:

Atividade de responsabilidade do gerente do projeto. Os pontos discutidos na reunião de acompanhamento e controle devem ser registrados em ata e distribuídos a todos os componentes da equipe. O Plano de Projeto deve ser atualizado caso sejam necessárias adaptações na equipe, negociação de mais recursos junto aos gestores, atualizações no cronograma (planejado x realizado), revisão dos riscos identificados, revisão dos custos e registro de pedidos de modificações realizados pelo cliente.

4.10.6.4 Comunicar interessados:

A ata da reunião de acompanhamento e controle deve ser distribuída a todos os componentes da equipe, indicando o encerramento da iteração que estava em curso. O módulo foi entregue formalmente e toda a equipe se concentrará a partir de agora no próximo módulo a ser desenvolvido.

4.10.7 Encerramento

4.10.7.1 Obter aprovação final do cliente:

Neste ponto do projeto todos os módulos foram aprovados individualmente e o cliente recebeu o software por completo após entregas sucessivas e incrementais. Apesar do cliente estar participando desde o início do processo, somente aqui é que ele terá em mãos o software completamente funcional e integrado. O gerente do projeto deve promover uma reunião que funcionará como um marco, pois a aceitação (ou não) do cliente quanto a entrega do produto completo é que determinará a continuidade ou encerramento do projeto. O aceite ou pedidos de mudança devem ser devidamente documentados e registrados para consulta posterior a qualquer momento. Os pedidos de mudança dificilmente refletirão nos requisitos neste momento, pois o projeto está em seu final e só há espaço para correções pontuais. Muito provavelmente pedidos de melhoria se converterão em um novo projeto a ser aprovado, iniciado e conduzido no futuro.

4.10.7.2 Realizar pesquisa de satisfação:

Boa prática, necessária para avaliar se o principal objetivo do projeto, que é atender às expectativas do cliente, foi atingido. A pesquisa de satisfação deve ser aplicada junto ao cliente e sua equipe e servirá como a principal ferramenta para avaliar o sucesso do projeto.

4.10.7.3 Realizar reunião final:

O gerente do projeto deve reunir toda a equipe e os dados necessários, incluindo a pesquisa de satisfação do cliente e registrar as lições aprendidas durante o projeto. Todas as lições que envolverem outras partes interessadas devem ser imediatamente comunicadas de modo a evitar a reedição de problemas durante os próximos projetos. Todos os pontos devem ser registrados em uma ata de reunião.

4.10.7.4 Arquivar documentação:

todos os componentes da equipe e as partes interessadas e posteriormente arquivada. Toda a documentação produzida no decorrer do projeto também deve ser arquivada para funcionar como referência para futuros empreendimentos.

4.10.7.5 Encerrar projeto:

Comunicação formal deve ser enviada pelo gerente do projeto para todos os componentes da equipe indicando o seu encerramento e desmobilizando a equipe.

4.10.7.6 Comemorar:

A comemoração funciona como elemento motivador para os futuros projetos a serem conduzidos. A equipe se sente valorizada por ter seus feitos reconhecidos. Todos podem refletir sobre as conquistas realizadas, percebendo a satisfação de um trabalho bem feito. Muito provavelmente um forte compromisso pela qualidade está se firmando nesse momento, o que vir a garantir resultados ainda melhores e mais maduros.

5. Considerações Finais

A metodologia simplificada sugerida por este estudo considera que os processos de desenvolvimento e implantação de softwares em pequenas e médias equipes são bastante semelhantes entre si. A idéia básica é propor um padrão no sequenciamento de atividades e uniformização de procedimentos facilmente verificáveis por equipes de qualidade, não previstas aqui. A proposta, por ser simples, possibilita implantação rápida e permite que a maturidade de determinada instalação evolua paulatinamente de modo que processos mais complexos de controle possam ser inseridos, atendendo necessidades específicas de cada equipe de projeto.

Devido às afinidades identificadas entre o PMBoK e o RUP, não houve dificuldade em agregar as boas práticas de cada proposta. Buscou-se a simplificação, palavra-chave da proposta final, e espera-se que esse objetivo tenha sido alcançado. A objetividade dos Métodos “Ágeis”, com suas premissas que pregam um retorno às origens, inspiraram profundamente a proposta final.

5.1 Críticas

Restaram dúvidas quanto ao alcance da simplificação da proposta final, base de todo o estudo realizado. Pequenas equipes são normalmente sufocadas por seguidas demandas e acúmulo de responsabilidades entre seus componentes. Apenas um conjunto de casos práticos permitiria uma melhor avaliação desse aspecto, visto que o nível de formalização proposto, supostamente “simples”, pode ainda não ser adequado à realidade de pequenas e médias equipes voltadas para projetos de software.

O gerenciamento dos custos, conforme colocado pela proposta, mereceria melhor detalhamento, por se tratar de um quesito crítico em qualquer projeto. A idéia da simplificação pesou sobre esse aspecto, pois buscou possibilitar que pequenas equipes formalizem seus procedimentos com facilidade sem, teoricamente, perderem em produtividade. De qualquer modo, técnicas mais complexas podem ser incorporadas na medida da necessidade de cada equipe e uma recomendação de estudos é proposta mais adiante.

5.2 Sugestões

Dentre os resultados dos estudos realizados, percebeu-se o maior nível de maturidade da proposta para gerenciamento de projetos do Project Management

Institute, PMI. Apesar disso, a proposta da IBM, o Rational Unified Process, RUP,

possui maior afinidade com projetos voltados ao desenvolvimento e implantação de produtos de software. Diante disto, as omissões relativas à gestão de projetos detectadas na metodologia deveriam ser corrigidas, tornando-a mais completa.

Outro aspecto que merece destaque está na complexidade do RUP, característica que inviabiliza sua plena adoção por pequenas equipes de desenvolvimento. Uma pesquisa voltada para a concepção e divulgação de uma versão voltada para pequenas e médias equipes, certamente seria uma contribuição de grande alcance no mercado.

5.3 Recomendações

Uma sugestão para estudos complementares que podem vir a ser realizados está na implantação da metodologia proposta sob condições controladas. A eficácia do método seria aferida ao serem comparados os resultados obtidos por equipes de desenvolvimento de software de pequeno e médio porte antes e depois de sua adoção.

Outra possibilidade de estudo está no detalhamento de métodos de controle de custos e tempo. Eles podem ser baseados em casos de uso a serem implementados e/ou no método de Análise de Pontos de Função (APF), que, conforme Wikipedia (2006), é usado “para medir o tamanho de um sistema de informação e expressá-lo em um número de pontos de função1”.

1 Um ponto de função é uma unidade de medida para expressar a quantidade de funcionalidades que um sistema de informação provê. É uma métrica de software definida pela IBM em 1977 e reconhecida pela ISO para estimar o tamanho de um sistema de informação. Fonte: WIKIPEDIA (2006)

REFERÊNCIAS BIBLIOGRÁFICAS

DIAS, Marisa Villas Bôas, SOLER, Alonso Mazini. Agile Project Management, um

novo enfoque para o gerenciamento de projetos de desenvolvimento de sistemas de informação. Revista MundoPM. Rio de Janeiro-RJ: Mundo, V. I,

No 4. P.14-19, 2005.

HIGHSMITH, Jim. Agile Project Management: Creating Inovative Products. 2004, Addison-Wesley.

HIGHSMITH, Jim. Agile software Development Ecosystems. 2002, Addison-Wesley.

KRUCHTEN, P. - Introdução ao RUP, Rational Unified Process. 2004, Ciência Moderna, 3a edição.

MARTINS, J. C. C. - Gerenciando Projetos de Desenvolvimento de software com

PMI, RUP e UML. 2005, Brasport, 2a edição.

MICHALISZYN, Mario Sergio, TOMASINI, Ricardo – Pesquisa: Orientações e

Normas para Elaboração de Projetos, Monografias e Artigos Científicos.

2005, Vozes, 1a edição.

POSSI M. et al - Capacitação em Gerenciamento de Projetos, Guia de Referência

Didática. 2004, Brasport, 2a edição.

PMI - Project Management Body of Knowledge 2000. 2000, Project Management Institute, 1a edição.

VARGAS, R. - Análise do Valor Agregado em Projetos, Revolucionando o

Gerenciamento de Custos e Prazos. 2005, Brasport, 3a edição.

VARGAS, R. - Manual Prático do Plano de Projeto Utilizando o PMBoK Guide –

REFERÊNCIAS ELETRÔNICAS

BECK, Kent. Manifesto for Agile software Development. Disponível em http://agilemanifesto.org. Visitada em 09/09/2006.

CHARBONNEAU, Serge. Software Project Management - A Mapping between RUP and the PMBoK. Disponível em http://www- 128.ibm.com/developerworks/rational/library/4721.html. Visitada em 09/09/2006.

MAGALHÃES, Ana Liddy Cenni de Castro. O Gerenciamento de Projetos Desenvolvidos à Luz das Metodologias Ágeis. Disponível em http://www.pmimg.org.br/downloads/Palestra-GerenciamentoAgil.pdf. Visitada em 09/09/2006.

RUP. Rational Unified Process. Disponível em http://www.wthreex.com/rup/. Visitada em 09/09/2006.

WIKIPEDIA. A Enciclopédia Livre. Disponível em http://www.wikipedia.org.br. Visitada em 09/09/2006.

ANEXO I – TABELA DE DECISÃO

Critérios de avaliação Alternativa 1 Alternativa 2 Alternativa 3 Marca comparada A Marca comparada B Marca comparada C Deveres (pára/não pára)

Suporte a nível 3 X X X

Adesão ao perfil sugerido X X X

Tolerância a falhas X X X

Treinamento

Desejos Peso[P] Pontos Pontos Pontos Comentários Nota Total Comentários Nota Total Comentários Nota Total

Preço 4 U$ 103.332,00 4 16 U$ 85.290,14 5 20 U$ 44.761,12 10 40

Expansibilidade 2 Até 96P 10/100 7 14 Até 144P 10/100 10 20 Até 32P 10/100 2 4

Garantia 5 5 25 9 45 10 50

Presença no mercado 7 42% (fonte: Nonono) 10 70 2% (fonte: Nonono) 1 7 6% (fonte: Nonono) 2 14

Contrato de suporte 9 Fabricante 8 72 Fabricante 7 63 Da própria Rep. Local 10 90

Compatibilidade legado 8 10 80 8 64 6 48

Performance 6 48M PPS 10 60 40M PPS 8 48 18M PPS 4 24

Solução de software 10 Solução marca A 8 80 Solução marca B 10 100 Solução marca C 6 60

Capacitação técnica local 3 Rep. local A 9 27 Rep. local B 2 6 Rep. local C 10 30 Pontuação máxima [10xP]

Pontuação total 444 373 360

ANEXO II – MODELO DE PLANO DE PROJETO

< logotipo da empresa > _{Plano de Projeto <nome do projeto>}

Histórico de Revisão

Revisão Descrição Modificado por Data

0.1 Versão inicial do documento. 0.2

Definições, Acrônimos e Abreviações Termo Definição

Dúvidas e/ou sugestões sobre o documento, enviar e-mail para: <e-mail do gerente do projeto>

Índice

<em página isolada e com itens paginados conforme o preenchimento>

1. Introdução

1.1 Objetivo

<Informar o objetivo deste documento.>

1.2 Público-alvo

<Informar o público-alvo deste documento.>

1.3 Referências

<Informar quaisquer documentos referenciados a partir deste documento.>

2. Visão Geral do Projeto 2.1 Objetivo

2.2 Cliente

<Identificar o cliente do projeto.>

2.3 Escopo do Projeto

<Descreva as principais funcionalidades do produto a ser criado pelo projeto.>

2.4 Produtos do projeto

<Na lista abaixo, devem ser apresentados os artefatos a serem entregues ao final do desenvolvimento desse projeto (ex.: Executáveis, Manuais, etc.).>

Produtos

2.5 Premissas

<Informe as condições supostamente verdadeiras para a realização do projeto. >

2.6 Restrições

<Informe as limitações para o projeto, normalmente de tempo e recursos.>

2.7 Estrutura Organizacional

O organograma abaixo representa a estrutura de ligação entre participantes da equipe do projeto.

<Inserir aqui o organograma dos participantes do projeto.>

2.8 Equipe

<Na lista abaixo, apresente a lista de integrantes da equipe de desenvolvimento que participam do projeto e os papéis que cada uma delas executa. Os papéis aqui indicados devem estar de acordo com a metodologia de desenvolvimento.>

Matrícula Nome Papéis

2.9 Contatos

<Na lista abaixo, apresente a lista de pessoas não-pertencentes à equipe de desenvolvimento e a responsabilidade de cada um deles dentro do projeto.>

Nome Fone E-mail Responsabilidade

2.10 Ciclo de Vida

<Definir o ciclo de vida adotado pelo projeto: cascata, iterativo e incremental, espiral, etc.>

2.11 Cronograma

<Indicar as principais fases com seus respectivos marcos. Exemplos de fases: Iniciação, Elaboração, Construção e Transição.>

Fase Data de Início Data Final Marco

3. Planejamento de Riscos

<Na lista abaixo, devem ser apresentados os riscos associados ao projeto, impacto, probabilidade, as ações adotadas para mitigar ou eliminar tais riscos e as datas de identificação e eliminação do risco. Seguem abaixo alguns exemplos de categorias de risco.>

Categoria do risco: Recursos (hardware, software, humano, ...)

Descrição do Risco Ações Impacto* Probabilidade* Dt. Identificação Dt. Eliminação

* [Alto | Médio | Baixo]

Categoria do risco: Tecnológico

Descrição do Risco Ações Impacto* Probabilidade* Dt. Identificação Dt. Eliminação

<Descrever os riscos de outras categorias.>

4. Planejamento da Infra-estrutura

4.1 Estimativas de Investimento em software:

Na tabela abaixo estão descritos os investimentos necessários: <exemplos: Sistema

Operacional, Sistema de Gerenciamento de Banco de Dados, Ferramentas de Desenvolvimento, outros>

4.2 Estimativas de Investimento em Hardware:

Na tabela abaixo estão descritos os investimentos necessários: <exemplos: Servidores,

Estações de Trabalho, Impressoras, outros>

Descrição Qtde. Custo

4.3 Estimativas de Investimento em Qualificação Profissional:

Na tabela abaixo estão descritos os investimentos necessários: <exemplos:

treinamentos, outros>

Descrição Qtde. Custo

4.4 Estimativas de Gastos com Material de Consumo:

Na tabela abaixo estão descritas as despesas necessárias: <exemplos: papel, toner,

outros>:

Descrição Qtde. Custo

5. Planejamento da Comunicação

<Determinar o que será comunicado, por quem, para quem, com que freqüência e de que forma>

Informação Responsável Destinatário Freqüência Forma / Meio

6. Acompanhamento do Projeto

6.1 Acompanhamento junto à equipe técnica:

<Informar como será feito o acompanhamento do progresso do projeto com a equipe técnica.>

• Periodicidade: • Participantes:

• Pontos a serem discutidos: <andamento das atividades, reavaliação dos

riscos, problemas e dificuldades encontradas.>

6.2 Acompanhamento junto ao cliente:

<Informar como será feito o acompanhamento do progresso do projeto junto ao cliente.>

• Formato: • Periodicidade: • Participantes:

• Pontos a serem discutidos: <andamento das atividades, reavaliação dos

riscos, problemas e dificuldades encontradas.>

7. Critérios para Aceitação dos Produtos

<Definir o processo e critérios de aceitação dos produtos que serão entregues.> <Local e Data> __________________________ <representante do cliente> __________________________ <representante da empresa>

ANEXO III – MODELO DE CRONOGRAMA

ANEXO IV – MODELO DE CONTRATO DE REQUISITOS

CONTRATO DE REQUISITOS

EMPRESA/SETOR: SOLICITADO POR: ID:

DATA:

SOLICITAÇÃO:

SERVIÇO A SER PRESTADO:

Descrição Detalhamento

Objetivo

Descrição Detalhamento

Atores envolvidos Patrocinadores Setores

Ambiente utilizado

Ciente do que foi disposto, firmamos a partir de agora, os serviços a serem prestados para este(a) setor/empresa. Qualquer alteração ou inclusão que seja necessária, deverá ser por escrito mediante solicitação enviada à ___________________.

_________________________ ________________________ SOLICITANTE GERENTE DO

ANEXO VIII – MAPEANDO PROCESSOS DO PMBoK ÀS ATIVIDADES DO RUP (CHARBONNEAU, 2004)

No quadro a seguir os processos do PMBoK são agrupados por áreas do conhecimento no formato <Número da seção no PMBoK> <Área do conhecimento>  <Processo>. Já as atividades do RUP são apresentadas no formato <Disciplina>  <Atividade>:

PROCESSOS DO

PMBoK ATIVIDADES DO RUP

4.1 Gerenciamento da Integração do Projeto  Elaboração do Plano do Projeto

• Gerenciamento de Projeto  Planejar Fases e Iterações • Gerenciamento de Projeto  Desenvolver Plano de Iterações

• Gerenciamento de Projeto  Desenvolver Plano de Aceitação do Produto

• Gerenciamento de Projeto  Compilar Plano de Desenvolvimento de software

• Gerenciamento de Projeto  Desenvolver Caso de Negócio • Requisitos  Desenvolver Visão

• Implantação  Desenvolver Plano de Implantação • Todas as atividades da disciplina Ambiente

4.2 Gerenciamento da

No documento 104-PROPOSTADEMETODOLOGIASIMPLIFICADAPARAPROJETOSDEDESENVOLVIMENTODESOFTWARESUTILIZANDOPMBoKERATIONALUNIFIEDPROCESS (páginas 51-75)