Evolução da Ferramenta dotProject para Suporte ao Encerramento

Transcrição

Suzana Vilas Boas Pescador
Evolução da ferramenta dotProject para
suporte ao encerramento de projetos
15 de Maio de 2012
Suzana Vilas Boas Pescador
Evolução da ferramenta dotProject para
suporte ao encerramento de projetos
Trabalho de conclusão de curso apresentado ao departamento de Informática e Estatı́stica do curso de graduação da Universidade Federal de Santa Catarina como
requisito final para obtenção do grau de
Graduação em Ciência da Computação.
Orientador:
Prof. Dr.rer.nat.Christiane Gresse von Wangenheim,PMP
U NIVERSIDADE F EDERAL DE S ANTA C ATARINA
C ENTRO T ECNOL ÓGICO
D EPARTAMENTO DE I NFORM ÁTICA E E STAT ÍSTICA
15 de Maio de 2012
Resumo
O gerenciamento de projetos em micro e pequenas empresas é, tipicamente, realizado com os artifı́cios de ferramentas de gerenciamento, que oferecem suporte à
determinados grupos de processo. Neste sentido, percebemos uma deficiência no
grupo de processo de encerramento de projetos, uma fase importantı́ssima na melhoria do processo da empresa. Este processo provê ao gerente e a equipe, técnicas,
dados e lições que representam oportunidades de melhoria, através da aprendizagem
contı́nua com base nas experiências vivenciadas. Neste cenário, as ferramentas de
gerenciamento open-source, em sua maioria, oferecem suporte mı́nimo ao encerramento de projetos. Portanto, este trabalho visa melhorar uma ferramenta de gerenciamento de projetos largamente usada no contexto de micro e pequenas empresas
brasileiras, o dotProject, adicionando suporte definido ao grupo de processo de encerramento de projetos. A implementação é feita com base em um modelo alinhado ao
PMBOK, também desenvolvido neste trabalho, que é focado para o contexto de micro e pequenas empresas. A evolução da ferramenta será testada e avaliada por um
painel de especialistas a fim de validar seu uso prático.
Sumário
Lista de Figuras
Lista de Tabelas
1 Introdução
p. 9
1.1 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 11
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 11
1.2.1 Objetivo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 11
1.2.2 Objetivos especı́ficos . . . . . . . . . . . . . . . . . . . . . . .
p. 11
1.3 Limites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 12
1.4 Metodologia de pesquisa . . . . . . . . . . . . . . . . . . . . . . . . .
p. 13
1.5 Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 14
2 Fundamentação Teórica
p. 16
2.1 Micro e Pequenas Empresas . . . . . . . . . . . . . . . . . . . . . . .
p. 16
2.2 Gerenciamento de projetos . . . . . . . . . . . . . . . . . . . . . . . .
p. 17
2.2.1 Encerramento de projetos . . . . . . . . . . . . . . . . . . . . .
p. 19
3 Estado da Arte e Prática
p. 31
3.1 Definição do estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 31
3.2 Avaliação das ferramentas . . . . . . . . . . . . . . . . . . . . . . . . .
p. 33
3.2.1 dotProject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 33
3.2.2 Project.Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 38
3.2.3 PhpCollab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 39
3.2.4 Track+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 40
3.2.5 Streber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 42
4 Modelo de um processo genérico de encerramento
p. 46
5 Evolução da ferramenta dotProject para encerramento de projetos
p. 50
5.1 A ferramenta dotProject . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 50
5.2 Análise de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 52
5.2.1 Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . .
p. 52
5.2.2 Requisitos não-funcionais . . . . . . . . . . . . . . . . . . . . .
p. 52
5.3 Projeto e implementação . . . . . . . . . . . . . . . . . . . . . . . . .
p. 53
5.3.1 Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 53
5.3.2 Modelagem da solução . . . . . . . . . . . . . . . . . . . . . .
p. 57
5.3.3 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 59
5.4 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 63
6 Avaliação
p. 66
6.1 Avaliação por painel de especialistas . . . . . . . . . . . . . . . . . . .
p. 66
6.2 Avaliação em relação ao alinhamento ao PMBOK
. . . . . . . . . . .
p. 70
6.2.1 Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 71
6.2.2 Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 71
6.3 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 71
7 Conclusão
p. 73
Referências Bibliográficas
p. 75
Apêndice A -- Código-fonte do módulo desenvolvido
p. 77
Apêndice B -- Formulário de avaliação
p. 105
Apêndice C -- Roteiro de simulação de uso do novo módulo
p. 108
Lista de Figuras
2.1 Grupos de processo de gerenciamento de projetos (PMI, 2008) . . . .
p. 19
2.2 Fluxo de dados no encerramento de projetos . . . . . . . . . . . . . .
p. 20
2.3 Processo de análise de pós-morte . . . . . . . . . . . . . . . . . . . .
p. 22
2.4 Participante da reunião de pós-morte colando post its, em uma sessão
de brainstorming (DINGSOYR; STALHANE; MOE, 2003) . . . . . . .
p. 24
2.5 Ata de reunião de pós-morte do projeto Pizzaria on line . . . . . . . .
p. 25
2.6 Interação dos seis passos do Paradigma de Melhoria da Qualidade
(BASILI; CALDIERA; ROMBACH, 1994) . . . . . . . . . . . . . . . . .
p. 27
2.7 Fábrica de Experiências (BASILI; CALDIERA; ROMBACH, 1994) . . .
p. 29
3.1 Relatório Task end date . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 35
3.2 Relatório User performance . . . . . . . . . . . . . . . . . . . . . . . .
p. 35
3.3 Relatório Project statistics . . . . . . . . . . . . . . . . . . . . . . . . .
p. 36
3.4 Janela de edição de um projeto . . . . . . . . . . . . . . . . . . . . . .
p. 36
3.5 Janela de visualização da empresa . . . . . . . . . . . . . . . . . . . .
p. 37
3.6 Janela de atividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 37
3.7 Janela de relatório de acompanhamento de tempo (PROJECT.NET,
2011b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 38
p. 40
3.9 Janela de atividade - Anexação de arquivos . . . . . . . . . . . . . . .
p. 40
3.10 Janela de atividade do Track+ . . . . . . . . . . . . . . . . . . . . . . .
p. 42
3.11 Janela de edição de projeto . . . . . . . . . . . . . . . . . . . . . . . .
p. 43
3.12 Janela de log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 43
p. 44
3.14 Janela de listagem de arquivos . . . . . . . . . . . . . . . . . . . . . .
p. 44
4.1 Modelagem do processo . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 47
5.1 Casos de uso do encerramento de projeto no dotProject . . . . . . . .
p. 54
5.2 Modelagem conceitual do módulo adicional de encerramento de projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 58
5.3 Arquitetura da ferramenta dotProject com o módulo de encerramento
p. 58
5.4 Diagrama de relacionamento de arquivos do módulo de encerramento
p. 59
5.5 Diagrama de relacionamento das tabelas no módulo de encerramento
p. 59
5.6 Tela de projetos, na aba de Arquivos . . . . . . . . . . . . . . . . . . .
p. 60
5.7 Tela de seleção de relatórios . . . . . . . . . . . . . . . . . . . . . . .
p. 61
5.8 Tela do projeto, com botão para adicionar uma nova ata . . . . . . . .
p. 61
5.9 Tela de nova ata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 62
5.10 Tela de edição de ata . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 63
5.11 Tela da empresa, na aba Base de Experiências . . . . . . . . . . . . .
p. 63
5.12 Tela de visualização da ata . . . . . . . . . . . . . . . . . . . . . . . .
p. 64
6.1 Gráfico da avaliação da questão 1.1 . . . . . . . . . . . . . . . . . . .
p. 68
p. 68
p. 69
p. 69
p. 70
Lista de Tabelas
2.1 Processos e áreas de conhecimento (PMI, 2008) . . . . . . . . . . . .
p. 20
2.2 Agenda de uma reunião de pós-morte (DINGSOYR; STALHANE; MOE,
2003) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
p. 23
3.1 Avaliação dos critérios (PEREIRA; GONçALVES; WANGENHEIM, 2011) p. 32
3.2 Tabela de resultado da avaliação das ferramentas . . . . . . . . . . .
p. 45
4.1 Entradas, técnicas e saı́das do modelo proposto . . . . . . . . . . . .
p. 47
4.2 Detalhamento da etapa E1 . . . . . . . . . . . . . . . . . . . . . . . .
p. 48
p. 48
p. 49
5.1 Tabela de execução dos testes . . . . . . . . . . . . . . . . . . . . . .
p. 65
6.1 Tabela de resultado da avaliação das ferramentas, atualizado com o
módulo de encerramento . . . . . . . . . . . . . . . . . . . . . . . . .
p. 71
9
1
Introdução
Vivenciamos uma sociedade altamente adaptada e dependente de serviços de
software. Eles estão presentes nos bancos, no comércio, nas comunicações e até nas
padarias. E com o crescimento do uso e da aplicação dos softwares, cresce também a
demanda por estes produtos e também por idéias inovadoras, que tragam ainda mais
comodidade ao cotidiano (SOFTEX, 2011).
Tais fatores têm impulsionado o setor brasileiro de desenvolvimento de software e
serviços, que no ano de 2010 teve um crescimento de 24%, alcançando o 11◦ lugar no
ranking mundial, segundo dados da ABES (2011). Este desenvolvimento da indústria,
movimentou neste mesmo ano - apenas no setor de software - cerca de 5,51 bilhões
de dólares. Esta fatia de mercado é dividida entre cerca de 8.520 empresas, dentre
as quais, 94% se caracterizam como micro ou pequenas empresas. Micro e Pequenas Empresas (MPEs), de acordo com a definição de SEBRAE (2011) são aquelas
que possuem equipes de 0 a 9 pessoas (para micro empresas) e 10 a 49 (no caso
de pequenas empresas). No caso especı́fico das brasileiras, outras caracterı́sticas
marcantes destas empresas, segundo (CEZARINO; C., 2005), são a gestão informal,
baixo nı́vel gerencial e escassez de recursos.
Em termos de empresas de software, este baixo nı́vel gerencial pode interferir no
sucesso de um projeto. Furtado (2011) afirma que a maioria das falhas nos projetos de
software vêm da falta de aplicação de metodologias de desenvolvimento, orientações
e boas práticas para planejar, construir e implantar software. Neste sentido, o gerenciamento de projetos, que segundo PMI (2008) é ”a aplicação de conhecimentos,
habilidades, ferramentas e técnicas às atividades do projeto para alcançar os requisitos do projeto”, age no sentido de minimizar essas falhas.
Faz parte do processo de gerenciamento de projetos identificar requisitos, atender
às necessidades, expectativas e preocupações dos stakeholders (partes interessadas
no projeto). Espera-se saber adequar e monitorar os recursos de acordo com as priori-
10
dades definidas, balanceadas entre as restrições de custo, escopo, tempo e qualidade
(tripla restrição). O ciclo de vida de gerenciamento de um projeto é dividido em 5
grupos de processos: iniciação, planejamento, monitoramento e controle, execução e
encerramento.
Dentro desse ciclo de vida, o grupo de encerramento compreende basicamente
as atividades de liberar uma versão final do produto ou serviço, encerramento administrativo, liberação da equipe, atualização de arquivos e retrospectiva do projeto.
Nesta fase, é importante uma coleta de dados e lições aprendidas sobre o projeto e
uma comparação entre o planejado e o executado para que, desta forma, possam ser
levantados e corrigidos estimativas, deficiências, problemas, riscos, entre outros.
Levantar estes dados e lições aprendidas é uma atividade crucial da parte de
encerramento, que é feita tipicamente em reuniões de pós-morte (BIRK; DINGSOYR;
STALHANE, 2005), onde se faz uma revisão do projeto, desde seu planejamento, a
fim de identificar, analisar e armazenar pontos fracos e fortes ocorridos durante o projeto. Com estas informações devidamente levantadas e analisadas, pode-se criar, ao
longo do tempo, uma fábrica de experiências (BASILI; CALDIERA; ROMBACH, 1994),
que pode servir de base para planejar, executar e monitorar projetos futuros. Dessa
forma, a realização do encerramento representa, também, um passo importante para
a melhoria contı́nua.
Para um gerenciamento mais eficiente e eficaz, são utilizadas ferramentas de software que auxiliam este processo. Dentre estas ferramentas, temos implementações
e estilos dos mais variados tipos e gostos. Contam-se com opções de software livre,
proprietário, especializadas em um processo ou mais genéricas, versões para dispositivos móveis, entre outros.
Naturalmente, como MPEs que dispõe de recursos limitados, muitas empresas
buscam soluções de software livre, onde não há custo de obtenção e de uso do software. Dentro deste cenário, o dotProject (2011a) é uma ferramenta web de gerenciamento de projetos freeware, distribuı́da sob licença GPL (GNU, 2011). Este software
é largamente utilizado no contexto empresarial brasileiro, o que tornou o Brasil o paı́s
top downloader desta ferramenta, segundo estatı́sticas de Sourceforge (2011).
11
1.1
Problema
Muitas das ferramentas de gerenciamento de projetos oferecem um modelo e suporte bem definido para criação e acompanhamento de tarefas, cronograma, recursos
e horas gastas na execução de cada tarefa, entre outros. Estas funcionalidades são
comumente observadas nas ferramentas de gerenciamento, uma vez que constituem
um controle mais básico e tem um impacto mais imediato na execução do projeto.
Entretanto, em um contexto geral, encontra-se uma deficiência destas ferramentas
em relação ao grupo de processo de encerramento de projetos, que é uma importante
parte do gerenciamento quando se trata da melhoria contı́nua da empresa e da equipe.
O suporte fornecido pelas ferramentas, atualmente, é incompleto e parcial, uma
vez que as funcionalidades não foram criadas para o propósito de encerramento. Ou
seja, podemos simular algumas atividades deste grupo, utilizando-se de funcionalidades originalmente criadas para outros grupos de processo. Porém, esta prática
não é eficiente, uma vez que não há disponı́vel um modelo definido para uso destas
funcionalidades, somada ao fato de elas não serem completas.
Especificamente, a ferramenta dotProject, que é uma ferramenta open source bastante utilizada no contexto empresarial brasileiro (SOURCEFORGE, 2011) também
não oferece este tipo de suporte completo, apresentando-se deficiente neste quesito.
1.2
Objetivos
Os objetivos especı́ficos e o objetivo geral deste trabalho são detalhados a seguir.
1.2.1
Objetivo geral
O objetivo geral deste trabalho é desenvolver um módulo de suporte ao encerramento de projetos na ferramenta de gerenciamento dotProject, alinhado ao conjunto
de boas práticas definidas no PMBOK.
1.2.2
Objetivos especı́ficos
Dentre os objetivos especı́ficos do trabalho estão:
12
• O1. Analisar a fundamentação teórica, em relação ao gerenciamento de projetos, ao encerramento de projetos, à ferramenta dotProject e às necessidades
das MPEs.
• O2. Analisar o estado da arte das principais ferramentas open source em relação
ao suporte fornecido ao encerramento de projetos.
• O3. Definir um processo genérico para encerramento, personalizado para MPEs
e alinhado ao PMBOK.
• O4. Evoluir o dotProject, baseando-se no modelo definido.
• O5. Avaliar a utilidade da evolução desenvolvida e o alinhamento ao PMBOK.
1.3
Limites
Os limites do escopo deste trabalho são:
• L1. Estudo detalhado, modelagem e implementação de um módulo de gerenciamento de encerramento de projetos. Outros grupos de processo de gerenciamento não se encaixam no escopo deste trabalho.
• L2. A implementação do módulo será feita especificamente para a ferramenta
dotProject. Outras ferramentas serão usadas, no contexto deste trabalho, para
fins de análise e comparação.
• L3. O módulo a ser desenvolvido deve estar alinhado às boas práticas definidas
no PMBOK, sendo que outros modelos de gerenciamento não serão considerados.
• L4. O escopo deste trabalho está limitado ao encerramento do projeto. Encerramento de aquisições não será tratado.
• L5. Serão levadas em consideração as necessidades de MPEs. Necessidades
especı́ficas de empresas de maior porte estão fora do escopo do trabalho.
13
1.4
Metodologia de pesquisa
A metodologia adotada para o desenvolvimento deste trabalho envolve estudo da
literatura no contexto geral e especı́fico, desenvolvimento e avaliação da implementação
realizada na ferramenta de gerenciamento de projetos dotProject.
Na primeira etapa, é feito um estudo detalhado sobre o processo de gerenciamento de projetos, focando no grupo de processos de encerramento, suas atividades,
entradas e saı́das. Também, segue um estudo e análise da ferramenta dotProject, novamente com foco no encerramento de projetos. Este estudo do processo de gerência
e ferramentas é feito no contexto empresarial brasileiro, que compreende micro e pequenas empresas, e é guiado pelo PMBOK. O estudo é realizado em 3 etapas:
• A1.1 Análise da gerência de projeto, com foco em encerramento de projetos
• A1.2 Análise da ferramenta dotProject
• A1.3 Análise das necessidades de micro e pequenas empresas brasileiras de
software, no que diz respeito à encerramento de projetos
A segunda etapa compreende uma revisão mais sistemática do suporte fornecido
pelas principais ferramentas software livre de gerenciamento de projetos. São selecionadas as cinco principais ferramentas open source para análise e discussão, no
que se refere à encerramento de projetos e alinhamento ao PMBOK. A seguir, as
atividades desta etapa:
• A2.1 Revisão da seleção das ferramentas e definição dos indicadores unificados
• A2.2 Análise dos critérios de avaliação
• A2.3 Documentação dos resultados e discussão
Na terceira etapa é modelado um processo genérico de encerramento de projeto,
voltada ao contexto de MPEs. A modelagem é feita definindo necessidades, etapas e
objetivos pertinentes ao cenário adotado, visto que, não há um processo bem definido
para a área de encerramento. Esta modelagem é feita com base em técnicas de
modelagem de processo, definindo as etapas e sequência, onde, para cada etapa, são
apontados os objetivos, atividades, entradas e saı́das. A terceira etapa é composta
pela atividade:
14
• A3.3 Modelagem do processo
A próxima etapa compreende o desenvolvimento do módulo de suporte à encerramento de projetos no dotProject. Para tal, é utilizado o framework de implementação
do dotProject para o desenvolvimento da evolução da ferramenta. O processo de
implementação compreende as seguintes atividades:
• A4.1 Análise de requisitos
• A4.2 Modelagem
• A4.3 Implementação
• A4.4 Testes
A etapa final é a avaliação do processo e módulo implementado. Para tal, é realizada uma avaliação da utilidade prática do módulo, feita por um painel de especialistas composto por gerentes de projetos. Estas avaliações seguem um plano que define
os objetivos, medidas e métodos de avaliação. Os dados são coletados, analisados e
discutidos. Realiza-se, também, uma avaliação do grau de atendimento aos requisitos
definidos no PMBOK. A etapa final é composta pelas atividades:
• A5.1 Realização da avaliação por painel de especialistas
A5.1.1 Definição da avaliação
A5.1.2 Execução da avaliação
A5.1.2 Coleta de resultados, análise e discussão
• A5.2 Avaliação do alinhamento ao PMBOK
1.5
Estrutura do trabalho
O trabalho está dividido em 7 capı́tulos: Introdução, Fundamentação Teórica, Estado da Arte & Prática, Modelo de um processo genérico de encerramento, Evolução
da ferramenta para encerramento de projetos, Avaliação e Conclusão. No segundo
capı́tulo, Fundamentação Teórica, estão agrupados os conhecimentos teóricos básicos
15
necessários para o desenvolvimento do trabalho. Também, estão detalhados os estudos realizados sobre o contexto empresarial brasileiro e os conceitos de gerenciamento de projetos, mais especificamente do grupo de encerramento.
O próximo capı́tulo, Estado da Arte & Prática, apresenta um estudo comparativo
das 5 principais ferramentas open-source de gerenciamento de projetos, levantadas
com base em alguns critérios. Este estudo, tem o objetivo de identificar qualidades e
deficiências de cada uma, quando utilizadas no cenário de micro e pequenas empresas.
O quarto capı́tulo, Modelo de um processo genérico de encerramento, apresenta
um modelo de um processo genérico de encerramento, construı́do a partir das definições
de encerramento de projetos apresentadas no capı́tulo Fundamentação Teórica.
O quinto capı́tulo, Evolução da ferramenta dotProject para encerramento de projetos, apresenta a ferramenta dotProject, a modelagem do módulo a ser desenvolvido
e o detalhamento da implementação, assim como os testes de validação. O sexto
capı́tulo detalha o processo de avaliação do módulo desenvolvido, sob os pontos de
vista de utilidade e alinhamento ao PMBOK. Finalmente, o sétimo capı́tulo apresenta
as conclusões do trabalho.
16
2
Fundamentação Teórica
Este capı́tulo aborda em termos gerais as caracterı́sticas de Micro e Pequenas
Empresas, conceitos de gerenciamento de projetos e detalhamento do processo de
encerramento de projetos.
2.1
Micro e Pequenas Empresas
Tanto as pequenas, quanto as médias ou grandes empresas de software enfrentam problemas comuns da indústria de software, tais como avanço rápido da tecnologia, melhoria do seu processo de desenvolvimento, acompanhamento do crescimento da indústria, entre outros. Porém, no contexto de micro e pequenas empresas há um foco menor em propostas de solução para estes problemas, apesar
destas empresas representarem uma porcentagem, em alguns paı́ses, massivamente
maior(RICHARDSON; WANGENHEIM, 2007). E este contexto empresarial possui algumas caracterı́sticas relevantes, muitas vezes diferentes das caracterı́sticas de empresas de maior porte(CEZARINO; C., 2005), tais como:
• Baixo nı́vel gerencial.
• Gestão informal.
• Fraca maturidade organizacional.
• Estratégia intuitiva.
• Ausência de planejamento.
• Inexistência de dados quantitativos.
• Altas taxas de mortalidade.
17
No caso especı́fico de MPEs de software, ainda podem-se citar:
• Equipes de desenvolvimento pequenas
• Projetos de pequeno e médio porte
• Menos nı́veis de hierarquia
• Mais facilidade de comunicação
• Maior proximidade entre os membros da equipe
Estas caracterı́sticas podem ser aproveitadas para melhoria da empresa e da qualidade, se usadas da forma correta. Uma dessas formas é ter uma gerência de conhecimento estabelecida, pois - uma vez que a equipe se conhece, a comunicação flui
mais fácil e rapidamente e o gerente está mais próximo da equipe - conhecer e saber
lidar bem com as dificuldades e qualidades, pontos fortes e fracos da equipe pode ser
decisivo no cumprimento de prazos, orçamentos e qualidade do produto oferecido.
Neste cenário, estabelecer um processo de gerenciamento dos projetos e das
experiências pode contribuir com a melhoria da empresa e dos produtos, e aumentar
suas chances de sobreviver e competir no mercado (THIRY et al., 2006). Porém, as
maiores normas e modelos nesta área estão focados em grandes empresas, e se faz
necessária uma adaptação destas para o contexto de MPEs (ANACLETO et al., 2003).
2.2
Gerenciamento de projetos
Para melhor entender o processo e o conceito de gerenciar projetos é necessário
um esclarecimento sobre o que é um projeto e qual é o seu papel.
Um projeto, de acordo com PMI (2008), é um esforço temporário empreendido
no desenvolvimento de um produto, serviço ou resultado. Esta natureza temporária
indica um inı́cio e fim definidos, onde este final se dá tanto pelo alcance dos objetivos,
pelo cancelamento (por exemplo, não ser mais necessário) ou pelo insucesso. Cada
projeto cria, necessariamente, um resultado único. Mas, apesar de serem únicos, os
projetos podem ter elementos repetitivos sem afetar sua caracterı́stica de unicidade.
São diferentes das operações, que são esforços dispendidos em atividades repetitivas,
não únicos, que não possuem um fim definido. Por exemplo, a construção de uma casa
é um projeto que possui similaridade com outros projetos de casas, mas que resulta
18
em um produto único. Enquanto isso, a secretária da empresa de construção, que
atende telefonemas e anota recados, executa uma operação.
Gerenciar um projeto, habitualmente compreende identificar os requisitos e gerenciálos junto às partes interessadas, para que as expectativas, preocupações e necessidades destes sejam atendidas. Da mesma forma, cabe ao processo de gerenciamento equilibrar as restrições do projeto, que geralmente se dividem em custo, escopo, tempo, qualidade e riscos. PMI (2008) divide as atividades de gerenciamento
em cinco grandes grupos:
• Iniciação: Compreende o processo de contato com partes interessadas, definição
de um escopo e obtenção da aprovação formal para a execução do projeto.
• Planejamento: Engloba as ações de planejar escopo, tempo, qualidade, custos,
aquisições, comunicação, RH e riscos.
• Execução: Para esta etapa estão previstas as ações de execução do planejamento. Por exemplo, realização de aquisições, gerenciamento da equipe e das
partes interessadas, orientar a execução do planejamento, entre outras.
• Monitoramento e controle: Este processo prevê ações para acompanhamento
e controle do projeto, no que diz respeito ao planejamento.
• Encerramento: Esta fase prevê o fechamento do projeto. Inclui atividades de
arquivamento de artefatos do projeto e gerência de lições aprendidas.
Projetos de software, contém especificidades que devem ser levadas em conta.
(DIJKSTRA, 1979) comenta sobre a dificuldade de se programar e ser um bom programador. Também, sobre a dificuldade de se construir sistemas complexos, uma vez
que programar é uma atividade essencialmente abstrata e intelectual. Neste sentido,
uma correta aplicação do processo de execução do planejamento e monitoramento
e controle precisam ser constantemente atualizadas, pois nestas fases são onde irão
ser identificados requisitos mal avaliados ou desvios de estimativas. Outro fator importante, é que o processo de monitoramento e controle seja executado durante todo o
projeto, desde a iniciação, até o encerramento. A figura 2.1, baseada no PMBOK PMI
(2008) organiza os grupos de processos durante a vida do projeto.
Os conceitos de gerenciamento de projetos são também divididos em 9 áreas de
conhecimento. São elas: custo, escopo, tempo, recursos, riscos, aquisições, qualidade, comunicação e integração. Cada área de conhecimento destas, é utilizada por
19
Figura 2.1: Grupos de processo de gerenciamento de projetos (PMI, 2008)
meio de um ou mais processos. Por exemplo, o gerenciamento de tempo é feito nos
processos de planejamento e monitoramento e controle. O relacionamento completo
entre as áreas de conhecimento e os grupos de processo é mostrado na tabela 2.1.
As áreas destacadas serão o foco e o escopo deste trabalho.
2.2.1
Encerramento de projetos
Visão Geral
Encerrar o projeto ou a fase é o ponto do projeto onde é feita a validação do escopo
e objetivos do projeto concluı́do, fechamento administrativo do projeto, finalização das
atividades, entre outros (PMI, 2008). O PMBOK apresenta um processo de encerramento, onde são definidas entradas, saı́das, e ferramentas para a execução deste
grupo de processo.
As entradas são o plano de gerenciamento do projeto, as entregas aceitas pelo
cliente e ativos de processos organizacionais, que podem ser diretrizes de encerramento, informações históricas, base de experiências e lições aprendidas, informações
do esforço realizado, entre outros. As saı́das são a transição do projeto ao produto
pelo qual o projeto foi criado e a atualização de ativos de processos organizacionais.
Como ferramentas e técnicas temos a opinião especializada, que vai garantir padrões
de qualidade no encerramento do projeto. O relacionamento entre os artefatos de
20
Tabela 2.1: Processos e áreas de conhecimento (PMI, 2008)
entrada e saı́da neste processo são esquematizados na figura 2.2.
Figura 2.2: Fluxo de dados no encerramento de projetos
Adicionalmente, existem alguns métodos e processos que são executados nesta
fase e que visam o usufruto dos dados e experiências do projeto para gerenciamento
de conhecimento e aprendizagem e melhoria contı́nua. No contexto deste trabalho
abordam-se duas: a análise de pós-morte e a fábrica de experiências (derivada do
21
conceito do paradigma de melhoria da qualidade).
Para ilustrar o uso e práticas destes métodos, iremos utilizar ao longo deste trabalho um projeto de exemplo. O projeto exemplo ’Pizzaria On Line’ trata-se de um
sistema de entrega de pizzas on line, onde cada entregador de pizza terá um smartphone, no qual ele terá acesso ao sistema central para pesquisar informações e
comunicar-se com a pizzaria.
Análises de pós-morte
A análise de pós-morte, ou Post mortem analysis (PMA) é um método de gerenciamento de conhecimento, que captura experiências e lições aprendidas e as usa para
melhoria do processo. Estas experiências e lições aprendidas (que são fatos ou fatores identificados como ensinamentos sobre o projeto) são utilizadas para o processo
de aprendizagem organizacional, onde a história do planejamento e da execução do
projeto permite que se conheçam defeitos, qualidades, pontos fracos e fortes do processo de desenvolvimento e também organizacional. A análise de pós morte é dividida
em quatro etapas sequenciais(BIRK; DINGSOYR; STALHANE, 2005):
• Preparação: Na preparação é feita uma revisão do projeto, para identificar o que
aconteceu durante o projeto e assim refinar os focos da reunião. Nesta etapa são
revistos documentos do projeto, relatório, plano de gerenciamento, entre outros.
Documentos como relatórios de monitoramento do primeiro ao último dia podem
ser gerados nesta etapa.
• Coleta de dados: Esta etapa compreende a coleta de experiências e lições
aprendidas durante o projeto. Estas informações não devem ser somente de
aspectos negativos ou pontos fracos do projeto, mas sim, também, de pontos
fortes e aspectos positivos.
• Análise: Na análise, é conduzida uma sessão de feedback com os participantes,
que são basicamente a equipe e o gerente de projeto. Na análise são discutidas
as lições do que deu certo e que não deu certo no decorrer da execução do
projeto.
• Resultados e experiências: Nesta fase é criado um relatório do processo de
análise de pós-morte que contém: Descrição do projeto, os principais sucessos
e insucessos do projeto e um relatório da sessão de análise.
22
A segunda e a terceira etapas são executadas no contexto de uma reunião de pósmorte (DINGSOYR; STALHANE; MOE, 2003). Ao final desta reunião, deve existir um
documento relatando as experiências e lições aprendidas levantadas na reunião, de
uma forma clara e que possa ser reusado futuramente. A figura 2.3 esquematiza o processo de análise de pós-morte, baseando-se em Myllyaho1 et al. (2004) e Dingsoyr,
Stalhane e Moe (2003)
Figura 2.3: Processo de análise de pós-morte
As reuniões de pós-morte acontecem habitualmente no intervalo de 5 horas e
seguem uma agenda como a demonstrada na tabela 2.2
A etapa de Resultados e Experiências gera uma ata da reunião de pós-morte, que
conterá as informações debatidas na análise de forma resumida. No nosso projeto de
exemplo, esquematizaremos uma reunião de pós morte da seguinte forma:
• Na parte 1 da reunião é apresentado a todos os membros da equipe e ao gerente
presente, o projeto, os requisitos e o planejamento da reunião, de acordo com a
tabela 2.2.
• Na parte 2, são levantados os pontos fortes: Proximidade com o cliente, domı́nio
de tecnologia e desenvolvimento web e fácil adaptação à plataforma de desen-
23
Tabela 2.2: Agenda de uma reunião de pós-morte (DINGSOYR; STALHANE; MOE,
2003)
volvimento para smartphones MyPhone. Após este levantamento são priorizados os itens, de forma que cada item seja escrito em um post it e colocado em
um quadro visı́vel para todos, de acordo com a figura 2.4. A priorização dos
itens acontece na ordem de importância, ou seja, quais destes itens foram mais
decisivos para o sucesso ou conclusão do projeto ou fase.
• Após um intervalo, a reunião é retomada. O passo 3 é análogo ao passo 2, mas
neste são levantados os pontos fracos e aspectos negativos. Do projeto exemplo,
poderı́amos citar: atraso no fornecimento dos smartphones, dificuldade de testes
e biblioteca gráfica de difı́cil manipulação. Neste caso, a priorização dos itens
acontecerá no sentido de maior impedimento. Itens prioritários serão aqueles
que apresentaram maior obstáculo ou dificuldade para o desenvolvimento do
projeto.
• Passado o intervalo, agora mais longo, a equipe e o gerente se reúnem novamente para debater as causas do itens priorizados no passo 2. Ao exemplo,
temos que o smartphone MyPhone apresentou uma plataforma estabelecida e
fácil de lidar, sendo um bom ambiente de desenvolvimento; os clientes estavam
próximos e acessı́veis para eventuais reuniões e visualização de protótipos; a
parte web do projeto já era de conhecimento dos membros da equipe e foi rapidamente concluı́da.
• Após outra breve pausa, os itens priorizados no passo 3 são discutidos. No
projeto exemplo, observou-se que a plataforma de desenvolvimento apresentou
bom ambiente de desenvolvimento, porém, não apresentou estrutura de testes,
tomando mais tempo para estas atividades que o planejado. Também, o atraso
24
Figura 2.4: Participante da reunião de pós-morte colando post its, em uma sessão de
brainstorming (DINGSOYR; STALHANE; MOE, 2003)
no fornecimento dos smartphones atrasou algumas atividades do caminho crı́tico
do projeto. Constatou-se também, que a biblioteca gráfica escolhida possuia
muitos bugs e foi de difı́cil manipulação, atrasando as atividades de interface.
Com estes dados levantados, esclarecem-se possı́veis mal-entendidos sobre atrasos de cronograma, estouro de orçamentos, entre outros, tanto para a equipe quanto
para o gerente. Adicionalmente, esta troca de experiências permitirá uma escolha
mais acurada de tecnologias, processos ou técnicas no planejamento e execução
de futuros projetos em domı́nio similar. Para fechar a reunião, é então coletadas as
informações obtidas e resumidas na ata de pós-morte, como é mostrado na figura 2.5.
PMA são frequentemente usadas em empresas de jogos (MYLLYAHO1 et al.,
2004). O site Gamasutra(GAMASUTRA, 2011) disponibiliza algumas atas de PMAs
de jogos conhecidos. Existem também, grupos de empresas grandes de jogos que
executam mensalmente uma atividade similar à análise de pós-morte, são eles o
25
Figura 2.5: Ata de reunião de pós-morte do projeto Pizzaria on line
San Francisco Post Mortem (SAN FRANCISCO POSTMORTEM, 2011) e Boston Post
Mortem (BOSTON POSTMORTEM, 2011). Estes grupos, reúnem-se mensalmente
em reuniões informais para conversar e trocar experiências sobre o desenvolvimento
e uso dos jogos.
Aplicar PMA da forma correta permite à organização uma forma de gerenciamento
de conhecimento, aprendizagem contı́nua sobre o processo, documentação de boas
práticas e problemas, além de prover à equipe uma maior integração, resolução de
conflitos, aprendizagem, feedback sobre o trabalho de cada pessoa e do grupo, entre
outros (BIRK; DINGSOYR; STALHANE, 2005).
26
Paradigma de melhoria da qualidade
O Paradigma de melhoria da qualidade (QIP) é a base da Fábrica de Experiências,
desenvolvida por Basili, Caldiera e Rombach (1994). É o resultado da aplicação de
metodologias cientı́ficas para o problema do gerenciamento de qualidade de software
e relaciona-se com o ciclo Planejar/Executar/Verificar/Agir (DEMING, 1986), muito usado na indústria na implementação de gerenciamento de qualidade. O QIP organizase em cima de seis passos:
• Caracterizar: Este passo visa entender e caracterizar o ambiente, com base
em modelos, intuição, dados, etc. Criam-se linhas de base com os processos
existentes e caracterizam a criticalidade dessas baselines.
• Definir metas: Uma vez caracterizada a organização, o próximo passo é definir
metas quantificáveis para sucesso de projeto, melhoria de processo e desempenho.
• Escolher processo: Com metas definidas, passamos ao passo de escolher um
processo que melhor se adeque às metas e à caracterização levantada. Junto
com o processo, são definidos também, métodos, ferramentas, e outros artefatos
de suporte.
• Executar: Este passo visa a execução do processo e consequentemente a
construção de um produto. Adicionalmente, feedback do projeto deve ser coletado, com base nas metas definidas e atingidas.
• Analisar: Ao final do projeto, este passo é executado a fim de analisar os dados
coletados. Estes dados tem o poder de apontar possı́veis problemas, avaliar o
processo e as práticas adotadas, pontos fracos e fortes do projeto, entre outros.
• Empacotar: Finalizada a análise, as experiências aprendidas devem ser consolidadas em uma forma estruturada de conhecimento. Estes dados, novos ou atualizados, devem ser armazenados numa base de experiências e estar disponı́vel
para consulta em projetos futuros.
Estas seis etapas estão sequenciadas como mostra a figura 2.6. A caracterização
deve ser feita de forma que cada projeto se encaixe em uma classe bem definida. Essa
classificação irá permitir uma melhor definição de metas, avaliação e comparação com
27
Figura 2.6: Interação dos seis passos do Paradigma de Melhoria da Qualidade
(BASILI; CALDIERA; ROMBACH, 1994)
futuros projetos. Por exemplo, não faz sentido comparar dados de um projeto que
inclui implementação de funcionalidades totalmente novas, com um projeto que visa a
implementação de funcionalidades já conhecidas pela equipe.
O contexo no qual o projeto está inserido, vai permitir uma definição de metas
mais precisa. Como exemplos de metas mensurávies, poderı́amos ter, no contexto
de projetos com funcionalidades já conhecidas, finalização das atividades dentro do
tempo planejado, reusar/refatorar código já existente, entre outros. E com base nestas metas definir com mais segurança qual será o método, processo e ferramentas de
suporte que melhor irão contribuir com o projeto. Ao final do projeto, a análise e empacotamento das informações coletadas durante a execução permitirá maior acurácia
na definição e planejamento dos próximos projetos.
Para o nosso projeto Pizzaria On Line, a execução dos 6 passos resultaria em:
• Caracterizar:
1. O projeto se encaixa nas classes de desenvolvimento web e desenvolvimento para dispositivos móveis
2. A equipe é de 3 desenvolvedores e 1 gerente
3. Todo equipamento móvel deverá ser fornecido por terceiros
4. A duração estimada é de 3 meses, começando em março e terminando em
maio
5. Contabilizam-se 8 horas de trabalho diário por desenvolvedor.
28
• Definir metas:
1. O software dos smartphones deve ter boa usabilidade
2. O desempenho dos servidores deve ser garantido
3. O suporte técnico deve ser facilmente contatado
4. O cronograma não pode ser atrasado em mais de 1 semana
5. O orçamento não deve ultrapassar o planejado em 10%
• Escolher processo:
1. Será utilizado o smartphone MyPhone e a linguagem Cobra++
2. Todo o desenvolvimento e teste será realizado na plataforma do MyPhone
3. O processo de gerenciamento será baseado no SCRUM
4. Será utilizada a biblioteca gráfica padrão da linguagem
• Executar: Durante a execução do projeto, constatou-se, com base nas metas:
1. A usabilidade do software dos smartphones está sendo bem aceita
2. O desempenho dos servidores está como planejado
3. O suporte técnico ainda tem dificuldades de contato
4. O cronograma está atrasado 1 semana
5. O orçamento está controlado
• Analisar: Ao final do projeto, constataram-se os seguintes pontos:
1. A equipe teve fácil adaptação à plataforma MyPhone
2. A linguagem Cobra++ mostrou-se complicada para o contexto do projeto
3. A biblioteca gráfica foi de difı́cil manipulação
4. O contato próximo ao cliente facilitou eventuais reuniões de replanejamento
e resolução de dúvidas, em relação aos requisitos
5. A plataforma MyPhone apresentou deficiências no quesito testes automatizados
• Empacotar: Os dados coletados vão para a base de experiências, e serão
disponibilizados para consultas futuras.
29
Ou seja, com a execução deste processo, podemos levantar dificuldade e qualidades comuns à mesmas classes de projetos. Por fim, armazenar estas informações
pode garantir que os mesmos erros não se repitam futuramente. Por isso, estas
informações devem ser armazenadas em uma forma acessı́vel para futura consulta,
e, neste sentido, automação pode se tornar necessária, pois podem-se lidar com uma
quantidade grande de dados.
Criação e manutenção de uma fábrica de experiências
A Fábrica de experiências (BASILI; CALDIERA; ROMBACH, 1994) é uma organização
lógica e/ou fı́sica, utilizando como metodologia o Paradigma de Melhoria da Qualidade,
que age no sentido de minimizar os problemas de se construir software de alta qualidade, pela coleta e reuso de experiências de produtos de projetos.
O QIP prevê uma separação do desenvolvimento do projeto (Organização do Projeto) da parte de aprendizado e empacotamento de experiências (Fábrica de Experiências). Como demonstrado na figura 2.7, a fábrica de experiências irá suprir
o organização do projeto com a análise dos dados fornecidos, metas, ferramentas,
etc. Para a execução correta do processo, a fábrica necessita de constante feedback
de dados, lições aprendidas e caracterı́sticas de ambiente. O apoio ao projeto tem a
função de manter, facilitar e gerenciar os dados e o acesso a estes.
Figura 2.7: Fábrica de Experiências (BASILI; CALDIERA; ROMBACH, 1994)
A análise e interpretacão dos dados e lições é feita com base nas metas. Estes
dados podem ser usados para entender e caracterizar melhor a relação entre classe
30
de projetos e atributos (processo, métodos, ferramentas), servir de suporte para a
melhoria do processo e ser base para comparações, avaliações, predições e controle.
A base de experiências é um conjunto acessı́vel e integrado de experiências e
lições aprendidas analisadas, sintetizadas e empacotadas. Por exemplo, no projeto
Pizzaria On Line, uma das lições aprendidas foi que a biblioteca gráfica usada não
foi fácil de manipular, ou seja, no próximo projeto similar, pode ser estudado o uso de
uma biblioteca alternativa. Analogamente, como foi constatado atraso no fornecimento
dos equipamentos, para os projetos futuros, pode ser planejado o pedido antecipado
de equipamentos, troca de fornecedores, entre outros.
Porém, o reuso de experiências necessita de uma estrutura organizacional que
disponibilize um modelo de evolução de software que suporta reuso, processos de
gerenciamento de experiências e um mecanismo de integração dentre o modelo e
os processos. Neste contexto, a Fábrica de Experiências realiza este trabalho de
integração, pois coleta estas lições e experiências e as armazena de forma organizada
e facilmente recuperável.
31
3
Estado da Arte e Prática
Este capı́tulo aborda o estado da arte das ferramentas de gerenciamento de projeto, assim como uma avaliação do grau de suporte das principais, no que diz respeito
ao grupo de processo de encerramento de projetos.
3.1
Definição do estudo
Para melhor avaliar, é necessário que se estabeleça uma metodologia e critérios
de avaliação bem definidos, para que os resultados possam ser melhor compreendidos. Como definição dos critérios de avaliação, usam-se os principais modelos e
normas na área de gerenciamento, o PMBOK e o CMMI-DEV. Porém, o CMMI-DEV
não define práticas ou processos definidos para a área de encerramentos, então o guia
base desta comparação é o PMBOK. Também, é avaliado nas ferramentas o suporte
para as atividades de análise de pós-morte e criação e manutenção de uma fábrica de
experiências. A avaliação é realizada no módulo core das ferramentas selecionadas,
não sendo considerados plug in’s adicionais.
Critérios de avaliação
Com base nos estudos da fundamentação teórica, buscamos nas ferramentas,
suporte para as principais atividades de encerramento administrativo, reunião de pósmorte e fábrica de experiências. Foram levantados os seguintes suportes:
• S1. Monitoramento do andamento do projeto do primeiro ao último dia, comparado ao planejamento.
• S2. Ata de reunião de pós-morte.
• S3. Arquivamento do projeto e de artefatos do projeto (documentos, relatórios,
links).
32
• S4. Consolidação de experiências facilmente recuperável e acessı́vel, na forma
exata ou similar à uma Fábrica de Experiências.
Cada um dos itens acima descritos serão avaliados conforme o grau de suporte
oferecido pela ferramenta. Estes estão descritos na tabela 3.1
Tabela 3.1: Avaliação dos critérios (PEREIRA; GONçALVES; WANGENHEIM, 2011)
Escolha das Ferramentas
A escolha das ferramentas é baseada no trabalho de (PEREIRA; GONçALVES;
WANGENHEIM, 2011), que efetuou a busca de ferramentas no repositório SourceForge (2011), um dos maiores sites de software open source. A busca foi efetuada a
partir da frase project management na categoria ”Office/Business - Project Management”. A fim de filtrar somente as ferramentas web de gerenciamento de projetos,
as palavras desktop e groupware foram usadas como critérios de exclusão. Como
critérios de inclusão foram usados:
• Atualização realizada depois de 2008: Diminuir o risco de selecionar um projeto
inativo.
• Taxa de downloads semanal maior que 50: Filtrar as mais populares.
• Equipe de desenvolvimento maior que 4 pessoas: Diminuir o risco de descontinuidade.
• Foco em suporte para gereciamento de projetos tradicional.
Já como critério de exclusão foram levantados os seguintes itens:
• Ferramentas desktop que não possuem suporte para troca de informações pela
web.
33
• Suporte não exclusivo para gerenciamento de projetos.
• Ferramentas com grau de generalidade grande. Ferramentas que possuam apenas uma funcionalidade especı́fica de um grupo de processo se encaixam neste
critério.
• Foco em metodologias ágeis.
As cinco ferramentas que atenderam aos critérios de seleção foram as seguintes:
1. dotProject.
2. Project.net.
3. PhpCollab
4. Track+.
5. Streber.
3.2
Avaliação das ferramentas
Uma vez escolhidas as ferramentas, analisamos cada uma, em relação ao suporte
oferecido para o grupo de processos de encerramento, alinhado ao PMBOK.
3.2.1
dotProject
O dotProject (DOTPROJECT, 2011a) é uma ferramenta web-based de gerenciamento de projetos, desenvolvida em PHP e usando o banco de dados MySQL. Encerrar um projeto na ferramenta dotProject corresponde à troca de situação do projeto,
conforme a figura 3.4. Estas situações são úteis para classificar e separar os projetos, principalmente quando listados. São possı́veis 8 situações: Indefinido, Proposto,
Planejamento, Execução, Aguardando, Completo, Modelo e Arquivado.
Não somente no encerramento dos projetos, mas também durante a execução, podem ser gerados alguns relatórios, que podem atuar como monitoramento do projeto,
oferecendo suporte para o item S1. Possı́veis relatórios a serem gerados são:
34
• Allocated user hours: Mostra quantas horas cada usuário alocou em um determinado perı́odo de tempo.
• Completed: Tarefas completadas na semana passada.
• Overall Report: Mostra uma visão geral de todos os projetos.
• Overdue: Tarefas atualmente atrasadas.
• Project Statistics: Estatı́sticas do projeto, com status das tarefas.
• Tasks end date: Visualização da data de término real e teórica das tarefas.
• Task List: Visualização da lista de tarefas do projeto.
• Task Log: Visualização dos logs de tarefa do usuário.
• Tasks sorted by user: Mostra as tarefas alocadas à cada usuário.
• Upcoming: Tarefas a serem completadas na próxima semana.
• User performance: Mostra a quantidade de horas trabalhadas por usuário, em
comparação com a quantidade alocada para as tarefas.
Os relatórios Projects Statistics, Task end date e User performance se mostraram
interessantes para o contexto do trabalho. O relatório Task end date apresenta de uma
forma visual bem organizada, as tarefas com seus respectivos responsáveis, horas
alocadas, data final planejada, data da última atividade e se foi ou não concluı́do,
como mostra a figura 3.1.
Já o relatório User performance apresenta uma análise de desempenho de cada
colaborador da seguinte forma: Exibe as horas alocadas e trabalhadas, a porcentagem
do trabalho que foi de fato realizado (calculado com base na duração das tarefas) e a
eficiência do usuário (esta calculada com base nas tarefas concluı́das). A figura 3.2
apresenta o relatório de usuário.
Por sua vez, o relatório Project statistics é bem completo, apresentando uma visão
geral sobre o projeto. Como exemplificado na figura 3.3, o relatório apresenta um
gráfico de barras com dados do esforço do projeto: uma barra representa o esforço
completo, em andamento e pendente, e a outra barra representa o esforço completo,
atrasado e no prazo. Também, há um resumo das atividades, da situação geral do
projeto e do espaço usado para armazenamento de arquivos de projeto.
35
Figura 3.1: Relatório Task end date
Figura 3.2: Relatório User performance
Estes três relatórios aliados ao diagrama de Gantt são muito úteis na realização
de uma reunião de pós-morte, uma vez que apresentam dados resumidos sobre o
andamento do projeto, das tarefas e dos colaboradores. Logo, com estes dados, é
mais fácil de discutir problemas, potenciais e saber quais tarefas foram crı́ticas, quais
foram menos complicadas, entre outros.
Já as atividades (tasks), permitem adição de arquivos, registro de tempo trabalhado, progresso, registro de atividades (logs), como mostra a figura 3.6. Neste contexto, este formato de atividade, aliada aos relatórios, podem oferecer um suporte
básico ao item S2, a reunião de pós-morte. A atividade da reunião poderá ter sua ata
escrita no registro da atividade, e os relatórios acessados para coleta de alguns dados
36
Figura 3.3: Relatório Project statistics
Figura 3.4: Janela de edição de um projeto
do projeto. Porém, falta um acompanhamento melhor das tarefas e usuários desde o
primeiro dia do projeto ao último. Além disso, o registro da atividade atuar como ata
da reunião, pode dificultar o acesso aos dados e lições aprendidas. Também, a falta
de um template pode gerar a não padronização dos dados.
A ferramenta também permite o arquivamento de documentos e artefatos, e geração
de diagramas Gantt. A figura 3.5 mostra a janela de visualização da empresa. Nela
37
encontram-se uma lista de projetos ativos e arquivados, arquivos, geração de diagramas de Gantt, entre outros. Portanto, em questões de encerramento administrativo
(item S3), a ferramenta está adequada.
Figura 3.5: Janela de visualização da empresa
Figura 3.6: Janela de atividade
Não foi encontrado nenhum tipo de suporte a uma fábrica de experiências, correspondente ao item S4, na ferramenta. Os únicos dados acessı́veis sobre os projetos
estão na possı́vel geração de diagramas de Gantt, como mostrado na figura 3.5 e nos
relatórios.
38
3.2.2
Project.Net
O project.Net (PROJECT.NET, 2011c) é uma ferramenta web-based de gerenciamento de projetos. É open source, desenvolvida em Java com banco de dados Oracle.
As tentativas de instalação da ferramenta apresentaram problemas na formação do
banco de dados, portanto, não pode-se avaliar a ferramenta como usuário.
A avaliação feita, então, é baseada em documentação e features encontradas no
site da ferramenta. Com base nisso, avaliamos que a ferramenta apresenta suporte
ao item S1, pois apresenta registro de tempo nas tarefas (como mostra a figura ??, e
com essa informação, a possibilidade de: acompanhar horas gastas em cada tarefa,
comparar tempo estimado contra tempo efetivo, identificar recursos sub ou sobre alocados, entre outros.
Além disso, possui relatórios de acompanhamento de tempo, registros históricos
do tempo atual de finalização do projeto com estimativas, entre outros. Estes relatórios
podem ser exportados para formatos compatı́veis com Microsoft Excel e podem ser
gerados para toda a organização, sub-organizações ou apenas projetos. A figura 3.7
mostra a janela de geração de relatórios de acompanhamento de tempo.
Figura 3.7: Janela de relatório de acompanhamento de tempo (PROJECT.NET, 2011b)
Já quanto ao item S2, assim como em outras ferramentas, a ata de reunião de
retrospectiva deverá ser escrita na forma de atividades. Sendo assim, a ferramenta
não possui suporte definido especificamente para este fim.
Já para o arquivamento de artefatos, a ferramenta dispõe de funcionalidades de
39
upload de arquivos (PROJECT.NET, 2011a). Sendo assim, possui suporte ao item
S3. Porém, como percebido em outras ferramentas, o suporte ao item S4 não foi
encontrado na documentação da ferramenta.
3.2.3
PhpCollab
A ferramenta open source PhpCollab (PHPCOLLAB, 2011), desenvolvida em PHP
e distribuı́da sob licença GLP, é focada no gerenciamento de projetos do ponto de
vista do time e do cliente. Seu diferencial está no fato de o cliente ter uma visão e
acompanhamento do projeto.
Encerrar um projeto nesta ferramenta, como visto nas outras, significa troca de
estado. Os estados possı́veis de um projeto no PhpCollab são: Suspendido, Abrir,
Não Começado, Completo e Cliente Completo.
A ferramenta possui suporte para geração e arquivamento de relatórios do projeto.
Estes relatórios listam as tarefas e suas prioridades, data de finalização, projeto, entre
outros. Porém, este relatório não possui informações de tempo gasto em cada tarefa,
tempo planejado de cada uma, entre outros. Por isso, apesar de possuir a geração de
relatórios, a ferramenta possui suporte básico ao item S1, pelo fato de este relatório
não centralizar informações gerenciais úteis no processo de encerramento, sendo que
estas estarão disponı́veis apenas nas descrições das atividades.
O formato de atividades que a ferramenta possui, permite o registro da ata de
reunião de pós-morte, como mostra a figura 3.8. Além disso, a atividade permite a
criação de sub-atividades, anexação de arquivos, registro de horas trabalhadas, progresso, tempo estimado e atual, entre outros. Logo, para o registro da ata, a ferramenta oferece suporte, apesar de não ser projeto para este fim.
O arquivamento de artefatos do projeto é permitido através do upload de arquivos
na ferramenta e persistência dos relatórios eventualmente gerados. Não foi encontrado um local centralizado de upload e listagem de arquivos, somente é possı́vel ver
ou anexar um arquivo em uma atividade, como mostra a figura 3.9. Apesar de não
haver este local centralizado para acesso aos arquivos, podemos dizer que a ferramenta possui suporte para arquivamento de artefatos do projeto, correspondente ao
item S3.
O suporte para o item S4, assim como nas outras ferramentas, não foi encontrado.
40
Figura 3.9: Janela de atividade - Anexação de arquivos
3.2.4
Track+
Track+ (TRACK+, 2011) é uma ferramenta web-based de acompanhamento de
projetos. A ferramenta tem foco no acompanhamento de problemas, atividades e
riscos. É mais abrangente, e pode ser usada também para o desenvolvimento de
41
sistemas mecatrônicos e sistemas embarcados. Assim como as outras ferramentas
estudadas, o encerramento ocorre com a troca de status do projeto. No Track+ os
possı́veis estados são: aberto, analisado, nomeado, a processar, implementado, integrado, avaliando, fechado, suspenso.
A ferramenta possibilita a geração de relatórios e gráficos dos projetos, as opções
encontradas foram:
• Relatório Filtered history : Apresenta um relatório de perı́odo configurável com
as seguintes informações: adição/modificação/deleção de arquivos, módulos e
comentários, custo, status, prioridade, entre outros.
• Relatório Status over time: Relatório de problemas e tarefas, de acordo com
seu status.
• Gráfico Earned value chart: Gráfico de valor agregado
• Gráfico Open vs. Closed Start: Gráfico e relatório de problemas abertos e
fechados
• Gráfico do número de artefatos abertos vs. Pessoa Responsável
• Gráfico do número de itens nomeados (vs. estado do item) para vários
Utilizadores
• Gráfico do número de itens vs estado de vários projetos
• Gráfico do número de items novos criados nas últimas 4 semanas
• Gráfico de Gantt
• Gráfico de estatı́sticas do estado
Mas, estes relatórios não apresentam grande valor em termos de comparação de
planejado vs. executado, no contexto global de gerenciamento de projetos. Como o
foco da ferramenta é em tarefas e resolução de problemas, ela apresenta funcionalidades que atendem estes requisitos, mas deixam a desejar em outros. O fato de não
poder se registrar o tempo trabalhado em horas é um destes. Portanto, quanto ao item
S1, conclue-se que a ferramenta não possui o suporte adequado.
As tarefas (também chamadas de issues), permitem o upload de arquivos, descrição
da atividade, prioridade, datas de inı́cio e término, entre outros, como mostra a figura
42
3.10. Assim como as outras ferramentas, uma atividade de reunião de pós-morte pode
ser realizada e ter sua ata escrita na descrição da atividade. Ou seja, para o item S2,
a ferramenta está de acordo.
Figura 3.10: Janela de atividade do Track+
Apesar de não encontrar um lugar centralizado para os arquivos, como nas outras
ferramentas, o Track+ permite a anexação de arquivos às atividades. Portanto, para o
item S3, está adequada.
Não foi encontrado suporte para uma fábrica de experiências, correspondente ao
item S4.
3.2.5
Streber
A ferramenta Streber(STREBER, 2011) é uma ferramenta livre baseada em wiki de
gerenciamento de projetos. Assim como as outras ferramentas avaliadas, ela encerra
projetos, também, com a mudança de status. Os possı́veis são: template, undefined,
upcoming, new, open, blocked, approved e done. A figura 3.11 mostra a janela de
edição de projeto, onde pode-se alterar o status de um projeto.
Quanto à dados de monitoramento do projeto, foi encontrado um log de mudanças
do projeto, no formato mostrado na figura 3.12. Além disso, a ferramenta permite adi-
43
Figura 3.11: Janela de edição de projeto
cionar estimativas de tempo, e pior caso, e registro de horas trabalhadas na forma de
esforços(efforts). Porém, não foi encontrado um mecanismo de agrupamento destes
esforços em uma forma de relatório ou similar, para comparação ao planejado, de
forma que esta comparação deverá ser feita manualmente, e para cada atividade do
projeto. Portanto, quanto ao item S1, a ferramenta não dispôs de suporte satisfatório,
pois não ofereceu mecanismos eficientes de acompanhamento do projeto, principalmente no que diz respeito à comparação entre planejado e executado.
Figura 3.12: Janela de log
As atividades no Streber tem o formato demonstrado na figura 3.13. Permite o
registro de estimativas de tempo e pior caso, esforços, descrição, comentários, entre
outros. Similarmente às outras ferramentas, o formato da atividade permite que seja
usada para reunião de pós-morte, permitindo o registro da ata e anexação de arquivos.
44
A ferramenta permite o arquivamento de arquivos, através das atividades ou da
aba Files. A figura 3.14 mostra a interface de listagem de arquivos do projeto. Esta
funcionalidade atende ao suporte procurado no item S3.
Figura 3.14: Janela de listagem de arquivos
Não é encontrado nenhum tipo de suporte a uma fábrica de experiências, correspondente ao item S4, na ferramenta.
45
Discussão
Os resultados da avaliação das cinco ferramentas escolhidas estão resumidos na
tabela 3.2, de acordo com os critérios definidos na tabela 3.1. Através desta tabela,
pode-se perceber que o suporte, principalmente ao item S4 (referente à fábrica de
experiências) não é encontrado em nenhuma forma em nenhuma das ferramentas.
Já itens como arquivamento de documentos e registro da ata através da estrutura de
atividades sào encontrados, porém, não criados para o fim especı́fico de encerramento
de projetos.
Tabela 3.2: Tabela de resultado da avaliação das ferramentas
Os relatórios de monitoramento foram encontrados com forte caracterı́stica em
duas das ferramentas, project.Net e dotProject. Porém, o dotProject se sobressai
neste quesito pelo fato de possuir a geração de diagramas Gantt, que são uma forma
visual fácil e prática de acompanhamento do projeto, no que diz respeito à comparação
entre planejado e executado.
Com esta análise, fica claro que as ferramentas open source mais usadas não
possuem foco nas atividades de encerramento. Com isso, reforça-se o objetivo deste
trabalho, que irá somar valor ao uso da ferramenta dotProject e às experiências vividas
durante o projeto.
46
4
Modelo de um processo
genérico de encerramento
Para evoluir a ferramenta no suporte ao encerramento, precisa-se, primeiramente,
definir os passos dessa atividade. Para isso, é definido um modelo de encerramento
para MPEs, alinhado ao PMBOK, independente de ferramenta.
Este modelo tem como base as atividades definidas no capı́tulo 2. Por isso, parte
de duas premissas:
1. A empresa possui uma base de experiências, que é usada no planejamento dos
projetos.
2. Existem dados registrados sobre a execução e controle do projeto a ser analisado.
Este modelo é proposto para que haja uma orientação para micro e pequenas empresas que desejam executar o grupo de processo de encerramento de projetos, alinhado ao PMBOK. O propósito deste modelo é passar por todos os passos necessários
para esta execução de forma sistemática, atingindo os objetivos de aprendizagem
contı́nua, gerenciamento de conhecimento e melhoria do processo.
Unificando várias definições de encerramento de projetos, apresentadas no capı́tulo
2, definimos como entradas: os dados do projeto (vindo dos relatórios e diagramas
gerados pela ferramenta, por exemplo) e arquivos, documentos, e artefatos em geral
usados desde a etapa de planejamento do projeto. Como técnicas do processo temos
a análise de pós-morte e o arquivamento de artefatos do projeto. Como saı́da temos
dados da base de experiência atualizados, artefatos do projeto arquivados e a ata
da reunião de pós-morte. A tabela 4.1 esquematiza entradas, técnicas e saı́das do
modelo.
O modelo é composto de três etapas, onde a primeira e a última devem ser exe-
47
Tabela 4.1: Entradas, técnicas e saı́das do modelo proposto
cutadas pelo gerente e possı́veis assistentes e a segunda conta com o gerente e com
a equipe do projeto:
• E1. Arquivamento de artefatos do projeto e coleta de dados
• E2. Reunião de pós morte
• E3. Atualização da base de experiências
A figura 4.1, esquematiza o modelo de processo proposto.
Figura 4.1: Modelagem do processo
A seguir, as etapas E1, E2 e E3 são descritas em detalhes nas tabelas 4.2, 4.3 e
4.4, respectivamente.
48
E1. Arquivamento de artefatos do projeto e coleta de dados
Propósito
O objetivo desta etapa é o arquivamento de relatórios, termo de abertura do projeto, termo de aceitação, atas de reuniões e outros documentos e artefatos produzidos durante o planejamento, execução e monitoramento do projeto. Com
isso, tem-se um local centralizado de armazenamento de documentos, onde
poderão ser acessados estes arquivos para consultas, pesquisas, entre outros.
Entradas
Artefatos do projeto
Saı́das
Artefatos do projeto revisados e arquivados
Passos
1. Agrupar todos os artefatos do projeto.
2. Revisar os artefatos levantados, a fim de identificar possı́veis falhas, arquivos
faltantes ou em excesso, versões corretas, entre outros.
3. Armazenar em um local definido.
Responsável
Gerente de projetos
Participantes
Gerente de projetos
Tabela 4.2: Detalhamento da etapa E1
E2. Reunião de pós-morte
Propósito
O objetivo desta etapa é o levantamento de lições aprendidas. Este levantamento é realizado através de uma reunião de pós-morte com os integrantes da
equipe e posterior registro da ata desta. A reunião de pós-morte é um passo
fundamental de melhoria, tornando esta etapa de fundamental importância para
a aprendizagem contı́nua.
Entradas
Relatório de status do projeto
Saı́das
Ata de reunião de pós-morte, como a mostra a figura 2.5, apresentada no
capı́tulo 2.
Passos
1. Com o relatório de status e a equipe, é realizada a reunião de pós-morte, de
acordo com o definido no capı́tulo 2.
2. É registrada a reunião em uma ata de reunião de pós-morte
Responsável
Gerente de projetos
Participantes
Gerente de projetos, equipe de desenvolvimento e, possivelmente, stakeholders
49
E3. Atualização da base de experiências
Propósito
O objetivo desta etapa é, com os dados do projeto (principalmente no que diz
respeito à estimado versus executado) e lições aprendidas obtidas na reunião
de pós-morte, executar a atualização da base de experiências. Neste momento,
é importante o registro destes dados quantitativos, lições aprendidas e pontos
fracos e fortes, para uso em planejamento de projetos e referências futuras. Este
é o passo final do processo de encerramento.
Entradas
Ata da reunião de pós-morte e base de experiências
Saı́das
Base de experiências atualizada
Passos
1. Com a ata da reunião de pós-morte, extrair as informações aprendidas
2. Com base nessas informações, atualizar a base de experiências
Responsável
Gerente de projetos
Participantes
Gerente de projetos
50
5
Evolução da ferramenta
dotProject para encerramento de
projetos
O objetivo deste trabalho é melhorar a ferramenta dotProject para suportar o processo de encerramento de projetos no contexto de MPEs, alinhado ao PMBOK. Após
analisar a ferramenta, levantamos os requisitos e os casos de uso. Com estes dados,
modelamos, implementamos e testamos a solução proposta.
5.1
A ferramenta dotProject
O dotProject (DOTPROJECT, 2011a)é uma ferramenta web-based de gerenciamento de projeto que provê mecanismos de planejamento e controle para atividades,
cronograma, comunicação e aquisições. Distribuı́da sob licença GPL1 , é composta por
um módulo core que possui as funcionalidades acima citadas e mais módulos add-on,
que são desenvolvidos e distrı́buidos pela comunidade. A ferramenta é desenvolvida
na linguagem PHP e possui como banco de dados o MySQL.
O módulo core possui funcionalidades para um gerenciamento básico de projetos.
Isto inclui dotProject (2011b):
• Backup: É um módulo recente de backup do banco de dados da ferramenta.
Não se recomenda usar este módulo como único recurso de segurança por instabilidade.
• Calendário: Este módulo permite a visualização de datas de tarefas e compromissos.
1 GNU
General Public License é uma licença de software livre idealizada no contexto da Free Software Foundation, que permite ao usuário utilizar, modificar, redistribuir e aperfeiçoar o software.
51
• Organizações: As organização são as entidades que agrupam projetos, tarefas
e usuários. É necessária a existência de pelo menos uma organização para se
criar um projeto na ferramenta.
• Contatos: Permite o cadastro de contatos com endereço, nome e outras informações.
Estar na lista de contatos não permite à pessoa associada efetuar login no sistema.
• Departamentos: São subconjuntos contidos nas organizações. Permitem um
agrupamento mais refinado de usuários e tarefas.
• Arquivos: Funções básicas de armazenamento de arquivos e controle de versão
simples.
• Fóruns: Permite a criação de fóruns do projeto para discussões, notas e informações.
• Diagrama de Gantt: Fornece a criação de diagramas de Gantt baseados nas
tarefas e atividades definidas.
• História: É uma funcionalidade que provê um log histórico de mudanças e revisões.
• Links: Fornece suporte à gravação e disponibilização de links (para sites ou
locais internos/externos).
• Projetos: Um projeto, no contexto do dotProject, é o elemento que contém as
tarefas.
• Recursos: É o módulo que incorpora recursos não-humanos ao projeto.
• Procura inteligente: Esquema inteligente de procura pelos módulos do sistema.
• Administração de sistema: Inclui as opções de configuração da ferramenta.
• Tarefas: Tarefas são os componentes de trabalho. Nela são gravadas horas
gastas, usuários responsáveis, logs, entre outros.
• Administração de usuários: Esquema de gerenciamento de usuários.
• Relatórios: Este módulo de relatórios provê uma gama de relatórios do projeto. Este módulo será detalhado no decorrer do trabalho, pois será utilizado no
módulo a ser desenvolvido.
52
Já quanto aos módulos add-on, a ferramenta possui um framework de desenvolvimento, que dá suporte ao desenvolvimento destes módulos adicionais. Como exemplo destes temos: módulo de gerenciamento de riscos, gerenciamento de help desk,
métricas, entre outros.
Os módulos adicionais, por não necessariamente serem mantidos pela equipe
de desenvolvimento, podem ter qualidade variável. Para distribuição dos módulos
adicionais, a equipe da ferramenta sugere um conjunto padrões de codificação. A
documentação pode ser encontrada em dotProject (2011b).
5.2
Análise de Requisitos
Com base na ferramenta escolhida, são identificados os requisitos funcionais e não
funcionais, para que possam ser definidas as funcionalidades e o escopo do trabalho.
Abaixo estão listados os requisitos identificados.
5.2.1
Requisitos funcionais
RF1. O módulo deve apresentar uma tela que agrupa todos os arquivos que foram
anexados ao projeto.
RF2. O módulo deve ter um relatório final de acompanhamento do primeiro ao
último dia do projeto (relatório de status).
RF3. O módulo deverá possuir uma funcionalidade de criar, modificar e deletar
atas de reunião de pós-morte.
RF4. O módulo cria uma base de experiências básica, inicialmente contendo todas
as atas registradas.
5.2.2
Requisitos não-funcionais
RNF1. O módulo deverá ser implementado usando o framework de desenvolvimento do dotProject.
RNF2. Deverá ser usada a linguagem PHP e o banco de dados MySQL.
RNF3. O tempo de resposta do sistema não deve ultrapassar 1 minuto.
53
5.3
Projeto e implementação
Com base nos requisitos levantados e no modelo proposto, são identificados os
casos de uso, e com base nestes, é modelada e implementada a solução a ser desenvolvida.
5.3.1
Casos de uso
Neste cenário, são identificados os seguintes casos de uso, esquematizados na
figura 5.1:
1. Arquivar artefatos do projeto
2. Preparar a reunião de pós-morte
3. Registrar a ata da reunião de pós-morte
4. Editar uma ata já registrada
5. Utilizar a base de experiências da empresa
6. Utilizar a base de experiências do projeto
A seguir, são detalhados cada caso de uso.
1. Arquivar artefatos do projeto
Atores
Gerente de projeto
Pré-condições
O projeto foi encerrado.
Fluxo de eventos
1. O gerente entra na página do projeto.
2. Clica na aba Arquivos.
3. O gerente confere os arquivos já organizados pela ferramenta.
54
Figura 5.1: Casos de uso do encerramento de projeto no dotProject
4. O gerente anexa possı́veis arquivos faltantes, clicando em ”novo arquivo”no
canto superior direito da tela.
Pós-condições
Todos os arquivos do projeto estarão salvos, disponı́veis e agrupados na aba ”Arquivos”, do projeto.
2. Preparar a reunião de pós-morte
Atores
Gerente de projeto.
Pré-condições
Os dados do projeto já foram coletados e os arquivos do projeto agrupados.
Fluxo de eventos
55
1. O gerente entra na página do projeto.
2. O usuário clica em ”relatórios”.
3. O usuário clica em ”Project Statistics”.
4. É gerado o relatório de estatı́sticas do projeto, que será usado na reunião.
Pós-condições
Os dados e arquivos do projeto continuam inalterados.
3. Registrar a ata de reunião de pós-morte
Atores
Gerente de projeto
Pré-condições
Aconteceu uma reunião de pós-morte
Fluxo de eventos
1. O gerente navega até a página de projetos.
2. Clica na aba ”Análise de Pós-Morte”.
3. Clica em ”Nova pós-morte”.
4. Preenche os campos definidos.
5. Clica em ”submit”.
6. O sistema automaticamente atualiza a base de experiências com a ata recémregistrada.
Pós-condições
A ata registrada irá aparecer na lista de atas de reunião.
4. Editar uma ata já registrada
Atores
Gerente de projeto
56
Pré-condições
Existe pelo menos uma ata registrada.
Fluxo de eventos
1. O gerente navega até a página de projetos.
2. Clica na aba ”Análise de Pós-Morte”.
3. Clica no link da ata da reunião desejada.
4. Preenche os campos definidos.
5. Clica em ”submit”.
Pós-condições
A ata foi atualizada com os dados novos.
5. Utilizar a base de experiências da empresa
Atores
Gerente de projeto.
Pré-condições
O projeto está sendo planejado.
Fluxo de eventos
1. O gerente acessa a aba de ”Base de experiências”na página da empresa.
2. É apresentada a lista de atas registradas sobre todos os projetos, separadas
pelo nome do projeto, data de inı́cio e fim, data da reunião de pós morte e status do
projeto.
3. O gerente acessa os dados que precisa para o planejamento.
Pós-condições
A base de experiências continua inalterada.
6. Utilizar a base de experiências do projeto
57
Atores
Gerente de projeto.
Pré-condições
O projeto está sendo planejado.
Fluxo de eventos
1. O gerente acessa a aba de ”Análise de pós-morte”na página do projeto.
2. É apresentada a lista de atas de reunião de pós morte, separadas por data e
participantes da reunião.
3. O gerente acessa os dados que precisa para o planejamento.
Pós-condições
A base de experiências continua inalterada.
5.3.2
Modelagem da solução
A modelagem da solução partiu de dois componentes a serem implementados,
e dois a serem utilizados. A reunião de pós-morte utilizará os relatórios oferecidos
pelo dotProject para obter dados de execução e controle do projeto. Como a reunião
em si, não é uma funcionalidade oferecida pelo software, ela não será implementada.
Porém, o registro da ata será um componente previsto neste módulo. Adicionalmente,
o módulo contará com uma base de experiências e uma unidade agrupadora de arquivos do projeto, esta última já fornecida pelo módulo core da ferramenta. A figura
5.2 apresenta a modelagem conceitual do módulo proposto.
Modelagem da implementação
A modelagem da implementação foi realizada primeiramente, estudando-se a arquitetura do dotProject. Como demonstrado na figura 5.3, o sistema todo é baseado
em módulos. Desta forma, pode-se desenvolver o modelo acima proposto como mais
um módulo, a ser integrado à ferramenta pelo framework de desenvolvimento da
ferramenta, que faz este trabalho. O resultado final é mostrado na figura 5.3, pela
integração do módulo desenvolvido.
58
Figura 5.2: Modelagem conceitual do módulo adicional de encerramento de projetos
Figura 5.3: Arquitetura da ferramenta dotProject com o módulo de encerramento
Com esta arquitetura em vista, é utilizado o framework e a documentação oferecida pela ferramenta (DOTPROJECT, 2011b) para modelar a solução do módulo proposto. O diagrama de relacionamento de arquivos da figura 5.4 esquematiza a solução
dos requisitos 3 e 4, referentes à atas de pós-morte e base de experiências, visto que
os requisitos 1 e 2 (referentes a arquivamento de artefatos do projeto e geração de re-
59
latório de status) já são atualmente fornecidos pela ferramenta. De forma complementar, a figura 5.5 esquematiza as tabelas novas criadas com o módulo e as interações
dela com a tabela já existentes dos projetos.
Figura 5.4: Diagrama de relacionamento de arquivos do módulo de encerramento
Figura 5.5: Diagrama de relacionamento das tabelas no módulo de encerramento
5.3.3
Implementação
A evolução é desenvolvida com a linguagem de programação PHP e a interface é
elaborada com a linguagem de marcação HTML, assim como os outros módulos da
ferramenta e de acordo com o recomendado pelo framework. A persistência é feita
60
com o banco de dados MySQL, e o servidor utilizado foi o Apache. Todo o código da
aplicação está presente no apêndice A.
Abaixo, apresentam-se as telas de usuário, relacionadas com cada caso de uso
acima especificado. As telas dos casos de uso ”Arquivar artefatos do projeto”e ”Preparar
a reunião de pós-morte”, são provenientes dos módulos core da ferramenta. As telas
dos outros casos de uso são provenientes da implementação das funcionalidades faltantes na ferramenta, para o módulo proposto.
Caso de uso: Arquivar artefatos do projeto
Ao entrar na página de projetos, navega-se até a aba ’Arquivos’, confere-se os
arquivos já anexados e adicionam-se os arquivos faltantes, clicando em ’novo arquivo’
no canto superior direito da tela, de acordo com a figura 5.6.
Figura 5.6: Tela de projetos, na aba de Arquivos
Caso de uso: Preparar a reunião de pós-morte
Ao entrar na página de projetos, navega-se até o link ”relatórios”, que irá redirecionar para a página de seleção de relatórios. Nesta página, clica-se em ’Project
Statistics’ (como mostra a figura 5.7) e o relatório é então gerado.
Caso de uso: Registrar a ata de reunião de pós-morte
Ao entrar na página de projetos, clica-se na aba ”Reunião de pós-morte”. Nesta
aba, clica-se em ”Nova pós-morte”, de acordo com a figura 5.8. Ao clicar neste botão,
o usuário é redirecionado para tela de edição do projeto, que virá com os campos
61
Figura 5.7: Tela de seleção de relatórios
vazios, à exceção do nome do projeto, datas de inı́cio e fim e orçamento planejados,
conforme figura 5.9. Depois de preencher os campos da ata, clica-se em ’submit’ para
salvar a ata.
Figura 5.8: Tela do projeto, com botão para adicionar uma nova ata
Caso de uso: Editar uma ata já registrada
Ao entrar na página de projetos, clica-se na aba ’Análise de Pós-Morte’, como visto
na figura 5.8. A aba irá listar todas as atas já registradas até o momento. Ao clicar no
link da ata da reunião desejada, o usuário será redirecionado para a página de edição
de ata, como mostra a tela na figura 5.10.
Caso de uso: Utilizar a base de experiências da empresa
62
Figura 5.9: Tela de nova ata
Ao entrar na página da empresa, clica-se na aba ’Base de Experiências’. Nesta
aba irão estar listadas as atas registradas de todos os projetos, segundo a figura ??.
O usuário escolhe a ata que deseja visualizar, clicando sob o link da mesma. A tela
de visualização das atas é a apresentada na figura 5.12. Se o gerente deseja deletar
a ata, basta clicar no link ’delete pós morte’ no canto superior direito.
Caso de uso: Utilizar a base de experiências do projeto
Ao entrar na página da empresa, clica-se na aba ’Análise de Pós Morte’. Nesta
aba irão estar listadas as atas registradas de todos os projetos, segundo a figura 5.8.
O usuário escolhe a ata que deseja visualizar, clicando sob o link da mesma. A tela
de visualização das atas é a apresentada na figura 5.12. Se o gerente deseja deletar
a ata, basta clicar no link ’delete pós morte’ no canto superior direito.
63
Figura 5.10: Tela de edição de ata
Figura 5.11: Tela da empresa, na aba Base de Experiências
5.4
Testes
Os testes, no nı́vel do sistema, são definidos de acordo com os casos de uso. O
planejamento e execução dos testes está esquematizado na tabela da 5.1, que define
o caso de uso a ser testado, pré e pós condições, o procedimento usado e o status da
execução.
64
Figura 5.12: Tela de visualização da ata
Com base nos testes executados, verifica-se que as funcionalidades estão de
acordo com o esperado.
65
Tabela 5.1: Tabela de execução dos testes
66
6
Avaliação
Este capı́tulo apresenta uma avaliação inicial do módulo desenvolvido, com o objetivo de:
1. Avaliar a utilidade e usabilidade do módulo desenvolvido
2. Avaliar o alinhamento ao PMBOK atingido
Para realizar a avaliação os objetivos acima listados, respectivamente, são executados avaliação por painel de especialistas, definido na seção 6.1 e avaliação do
alinhamento ao PMBOK atingido, definido na seção 6.2.
6.1
Avaliação por painel de especialistas
Para a avaliação do módulo, foi adotado o método GQM (Goal/Question/Metric)
(BASILI; CALDIERA; ROMBACH, 1994). Este método de medição de software é basicamente dividido em 6 passos:
1. Identificar objetivos
2. Formular questões que abrangem os objetivos identificados
3. Especificar métricas para coletar respostas para as perguntas formuladas
4. Desenvolver mecanismos de coleta de dados
5. Coletar e validar os dados
6. Analisar os dados, a ponto de identificar pontos fortes e fracos
Com base nesse método, descrevemos a realização da avaliação a seguir.
67
Identificar objetivos
Os objetivos identificados para a avaliação deste trabalho foram:
• Objetivo 1: Analisar a utilidade e usabilidade do módulo desenvolvido no encerramento de projetos
• Objetivo 2: Identificar os pontos fortes e fracos da solução proposta
Formular questões
A partir dos objetivos identificados, são derivadas as seguintes questões de medição:
1.1 O módulo é útil para encerrar os projetos da empresa?
1.2 O módulo é útil para documentar as reuniões de pós-morte do projeto?
1.3 O módulo é útil para gerenciar lições aprendidas durante os projetos?
1.4 O módulo é útil para identificar pontos fortes e fracos da empresa, através das
lições aprendidas?
1.5 O módulo é de fácil manipulação e conteúdo intuitivo?
2.1 Quais foram os principais pontos fortes que você observou?
2.2 Quais foram as principais melhorias que você sugere?
Especificar métricas
Para responder as questões de 1 a 5, é adotada uma escala de likert de 5 pontos,
de 1 (Discordo totalmente) até 5 (Concordo totalmente). Já para as questões de 6 a
8, é definido um campo textual aberto.
Desenvolver mecanismos de coleta de dados
Foi criado um formulário na ferramenta Google forms, conforme as métricas definidas
acima. O formulário está presente no apendice B.
Coletar e validar os dados
Fizeram parte do painel de especialistas: gerentes e assistentes de gerência
de pequenas empresas de software e gerentes de projeto de uma organização de
68
pesquisa em Florianópolis/SC. Por restrições de tempo, os participantes foram escolhidos pela proximidade. De 6 especialistas convidados, 4 realizaram a avaliação,
que foi anônima e voluntária, e aconteceu no mês de abril do ano 2012. A avaliação
ocorreu após a simulação de uso do novo módulo, de acordo com um roteiro definido
(presente no apêndice C).
Análise dos dados
As respostas obtidas foram analisadas item a item, a fim de identificar pontos fortes
e fracos da solução proposta.
Questão 1.1 - O módulo é útil para encerrar os projetos da empresa?
A figura 6.1, mostra que a maioria dos avaliadores considerou útil o módulo para
encerrar os projetos.
Figura 6.1: Gráfico da avaliação da questão 1.1
Questão 1.2 - O módulo é útil para documentar as reuniões de pós-morte do
projeto?
A figura 6.2, mostra que a maioria dos avaliadores considerou útil as funcionalidades de criação/edição/deleção de atas de pós-morte. Os comentários mostraram
que melhorias no formato da ata foram identificadas, assim como cálculo e preenchimento automático de alguns campos da ata.
69
Questão 1.3 - O módulo é útil para gerenciar lições aprendidas durante os
projetos?
A figura 6.3 demonstra a avaliação de gerência de lições aprendidas. Este item
teve uma avaliação menos positiva, fato compreensı́vel uma vez que a base de experiências implementada é apenas uma base simples, que serve de fundação para
desenvolvimento de mais funcionalidades. Sendo assim, pode-se considerar que o
item teve uma avaliação positiva, com sugestões interessantes de funcionalidades
para a base de experiências.
Questão 1.4 - O módulo é útil para identificar pontos fortes e fracos da empresa, através das lições aprendidas?
A figura 6.4 reflete um pouco do item discutido acima. Porém, este item teve uma
avaliação mais positiva, dado que a ata de pós morte permite o registro e persistências
dos pontos fortes e fracos identificados nas reuniões. Uma sugestão interessante foi
a de categorizar as lições, para facilitar a consulta.
Questão 1.5 - O módulo é de fácil manipulação e conteúdo intuitivo?
A avaliação de usabilidade foi positiva, tendo apenas uma avaliação menos positiva. Foi destacado a boa integração com a interface, consistência e simplicidade.
Em outra mão, foram sugeridas melhorias como prover uma forma de visualização da
70
ata onde possam ser visualizado mais do seu conteúdo, campos de preenchimentos
maiores, entre outros.
Questão 2.1 - Quais foram os principais pontos fortes que você observou?
Neste item foi percebido que, o ponto forte do módulo está no registro/edição/deleção
das atas. Também, foi destacada a utilidade real em projetos, simplicidade e boa
integração com a interface e funcionalidade relevante e não existente na ferramenta.
Questão 2.2 - Quais foram as principais melhorias que você sugere?
As principais melhorias foram no formato de visualização da ata, cálculo e preenchimento automático de campos, envio da ata por e-mail, aprovação dos participantes na
parte das atas de pós-morte. Foi citado também que seria interessante um aceite formal do encerramento do projeto, por parte do cliente. Já na parte de lições aprendidas,
foram sugeridas, principalmente, a categorização de lições e a coleta da informações
das atas e, com a manipulação destes dados, criar uma base de experiência mais
complexa e completa.
6.2
Avaliação em relação ao alinhamento ao PMBOK
A fim de avaliar se o módulo desenvolvido está alinhado com as boas práticas recomendadas pelo PMBOK para o encerramento de projetos, é realizada uma avaliação.
Esta avaliação segue o mesmo procedimento adotado na revisão do estado da arte,
conforme descrito no capı́tulo 3.
71
6.2.1
Execução
Foi refeita a avaliação de atendimento aos suportes definidos no capı́tulo 3, a fim
de avaliar se a ferramenta, com o módulo desenvolvido, caracteriza melhor o suporte
ao grupo de processo de encerramento de projetos. A avaliação foi realizada pela
autora do trabalho, em abril de 2012, após a execução dos testes.
6.2.2
Análise
O resultado da avaliação dos módulos desenvolvido em relação ao alinhamento
ao PMBOK é apresentado na tabela 6.1. O grau de suporte adotado está descrito na
tabela 3.1 do capı́tulo 3.
Tabela 6.1: Tabela de resultado da avaliação das ferramentas, atualizado com o
módulo de encerramento
Com essa avaliação, foi constatado que a ferramenta evoluı́da atende melhor às
boas práticas definidas no PMBOK. Também, temos funcionalidades do grupo de
encerramento de projetos, construı́das para este fim, não necessitando a adaptação
de utilidades existentes para simular uma funcionalidade.
6.3
Discussão
A partir das avaliações por painel de especialistas e avaliação em relação ao alinhamento ao PMBOK, pode-se perceber que o módulo desenvolvido teve boa aceitação
72
e adequação para implementação do grupo de processo de encerramento de projetos.
Porém, a avaliação apresenta ameaças de validade, pois o projeto usado de exemplo foi um projeto fictı́cio sem continuidade e foi realizado envolvendo poucos especialistas e de proximidade com a autora do trabalho. Dessa maneira, a generalização
dos resultados está limitada e outras avaliações com outros projetos, outros tipos de
empresas e mais especialistas, precisam ser realizadas a fim de generalizar os resultados obtidos neste trabalho.
Como meio de minimizar a ameaça à validade construtiva dos resultados das
avaliações, foi utilizado o método GQM, que permite realizar a análise de forma sistemática. Sendo assim, o objetivo das avaliações realizadas não é ser uma avaliação
nem subjetiva nem completa, mas sim apresentar primeiros indı́cios de que a evolução
da ferramenta pode ser relevante e útil.
73
7
Conclusão
Neste trabalho foi desenvolvida a análise da teoria referente à gerenciamento de
projetos, com foco no encerramento de projetos. Foi analisado o estado da arte das
ferramentas open source de gerenciamento de projetos, em relação ao suporte ao
grupo de processo de encerramento de projetos. Foram comparadas as cinco ferramentas mais usadas, e escolhida uma ferramenta, na qual foi desenvolvida este
trabalho.
Partindo da fundamentação teórica e da análise do estado da arte foi modelado um
processo genérico de encerramento de projetos, guiado pelo PMBOK, para utilização
em MPEs. A partir deste modelo, foram analisados os requisitos, projetado, implementado e testado o módulo na ferramenta dotProject. Uma vez desenvolvido o módulo,
foi definida e realizada uma avaliação com um painel de especialistas, a fim de validar
o uso prático do trabalho desenvolvido e estudar o alinhamento ao PMBOK atingido.
Com esse novo módulo, espera-se facilitar e viabilizar a implantação sistemática
de encerramento de projetos aliada à gerência de lições aprendidas. Com isso, esperase que as experiências tenham usufruto máximo na aprendizagem contı́nua das micro
e pequenas empresas brasileiras. Além disso, procura-se prover uma ferramenta que
maximize os grupos de processos para um gerenciamento de projetos mais completo
e eficaz.
Para trabalhos futuros, com base nas sugestões de melhoria identificadas pela
avaliação, podem-se citar no quesito da Fábrica de Experiências: o aperfeiçoamento
da base de experiências (utilizando técnicas de manipulação de dados, para classificar
projetos e analisar dados automaticamente), evolução da Fábrica atrelada a gerência
de reutilização, a categorização de lições aprendidas. No quesito das atas de pósmortem, sugere-se a geração de relatórios personalizados (para acompanhamento
dos projetos), o aceite formal do cliente (do encerramento do projeto), a aprovação da
ata por parte de todos os participantes da reunião e o envio da ata por e-mail para
74
todos os participantes.
75
Referências Bibliográficas
ABES. Associação Brasileira das Empresas de Software. 2011. Disponı́vel em:
<http://www.abes.org.br/>.
ANACLETO, A. et al. 15504mpe- desenvolvendo um método para avaliação de
processos de software em mpes utilizando a iso/iec 15504. 2003.
BASILI, V. R.; CALDIERA, G.; ROMBACH, H. D. The experience factory. 1994.
BIRK, A.; DINGSOYR, T.; STALHANE, T. Post-mortem: Never leave a project without
it. 2005.
BOSTON POSTMORTEM. Boston Postmortem. 2011. Disponı́vel em: <http://www.bostonpostmortem.org/>.
CEZARINO, L.; C., C. M. Micro e pequenas empresas: caracterı́sticas estruturais e
gerenciais. 2005.
DEMING, W. E. Out of the Crisis. [S.l.]: The MIT Press, 1986.
. Upper Saddle River, NJ,
DIJKSTRA, E. The humble programmer. In:
USA: Yourdon Press, 1979. p. 111–125. ISBN 0-917072-14-6. Disponı́vel em:
<http://dl.acm.org/citation.cfm?id=1241515% -.1241525>.
DINGSOYR, T.; STALHANE, T.; MOE, N. B. Lightweight post mortem reviews. 2003.
DOTPROJECT. dotProject - Project Management Software. 2011. Disponı́vel em:
<http://www.dotproject.net/>.
DOTPROJECT. dotProject Wiki. 2011. Disponı́vel em: <http://docs.dotproject.net/index.php?title=Main Page>.
FURTADO, A. Pontas de iceberg do caos no desenvolvimento de software. 2011.
Disponı́vel em: <http://www.microsoft.com/brasil/msdn/Tecnologias/Carreira/DesenvolvimentoSoftware.mspx>.
GAMASUTRA. Gamasutra - The Art & Business of Making Games. 2011. Disponı́vel
em: <http://www.gamasutra.com/>.
GNU. GNU General Public License. 2011. Disponı́vel em: <http://www.gnu.org/copyleft/gpl.html>.
MYLLYAHO1, M. et al. A review of small and large post-mortem analysis methods.
2004.
76
PEREIRA, A. M.; GONçALVES, R. Q.; WANGENHEIM, C. G. von. Comparação de
ferramentas open source para gerência de projetos. 2011.
PHPCOLLAB. PhpCollab. 2011. Disponı́vel em: <http://www.phpcollab.com/blog/>.
PMI. A guide to the project management body of knowlegde - (PMBOK Guide). 4. ed.
[S.l.]: Project Management Institute Inc, 2008. ISBN 978-1-933890-51-7.
PROJECT.NET. Easy-to-Use Personal Dashboards. 2011. Disponı́vel em: <http://www.project.net/personal dashboard>.
PROJECT.NET. Project Time Tracking Made Easy. 2011. Disponı́vel em: <http://www.project.net/time submittal reports>.
PROJECT.NET. Project.net. 2011. Disponı́vel em: <http://www.project.net/>.
RICHARDSON, I.; WANGENHEIM, C. G. von. Why are small software organizations
different? 2007. Disponı́vel em: <http://www.computer.org/portal/web/csdl%
-/doi/10.1109/MS.2007.12>.
SAN FRANCISCO POSTMORTEM. San Francisco Postmortem. 2011. Disponı́vel
em: <http://www.unknownworlds.com/postmortem>.
SEBRAE. Serviço Brasileiro de Apoio às Micro e Pequenas Empresas. 2011.
Disponı́vel em: <http://www.sebrae.com.br/>.
SOFTEX. Mercado nacional de software cresce 21,3% em 2010. 2011. Disponı́vel
em: <http://www.softex.br/ mercado/mercado.asp?id=3630>.
SOURCEFORGE. dotProject. 2011. Disponı́vel em: <http://sourceforge.net/projects/dotproject/files/dotproject/stats/map?dates=2001-02-27+to+2011-10-21>.
SOURCEFORGE. SourceForge. 2011. Disponı́vel em: <http://sourceforge.net>.
STREBER. Streber. 2011. Disponı́vel em: <http://www.streber-pm.org/>.
THIRY, M. et al. Uma abordagem para a modelagem colaborativa de processos de
software em micro e pequenas empresas. 2006.
TRACK+. Track+. 2011. Disponı́vel em: <http://www.trackplus.com/>.
77
APÊNDICE A -- Código-fonte do módulo
desenvolvido
78
addedit.php
1
<?php / ∗ PROJECTS $ I d : a d d e d i t . php 5433 2007−10−17 1 5 : 0 2 : 4 6Z g r e g o r e r h a r d t
$ ∗/
( ! d e f i n e d ( ’ DP BASE DIR ’ ) ) {
if
d i e ( ’ You should n o t access t h i s f i l e
3
directly ’ ) ;
}
5
$pma id = dPgetParam ( $ GET ,
’ pma id ’ , 0 ) ;
7
$project name = dPgetParam ( $ GET ,
9
$project name = ’ ” ’ . $project name . ’ ” ’ ;
11
’ project name ’ , 0) ;
$perms =& $AppUI−>a c l ( ) ;
/ / check p e r m i s s i o n s f o r t h i s r e c o r d
13
$ c a n E d i t = $perms−>checkModuleItem ($m,
’ e d i t ’ , $pma id ) ;
$canAuthor = $perms−>checkModuleItem ($m,
15
( ( ! $ c a n E d i t && $pma id > 0 ) | |
if
’ add ’ ) ;
( ! $canAuthor && $pma id == 0 ) ) {
$AppUI−>r e d i r e c t ( ’m= p u b l i c &a= access denied ’ ) ;
17
}
19
/ / l o a d t h e r e c o r d data
$row = new CClosure ( ) ;
21
i f ( $pma id > 0 && ! $row−>l o a d ( $pma id ) ) {
$AppUI−>setMsg ( ’ Post Mortem ’ ) ;
23
$AppUI−>setMsg ( ’ i n v a l i d I D ’ , UI MSG ERROR , t r u e ) ;
25
//
$AppUI−>r e d i r e c t ( ) ;
}
27
i f ( $pma id == 0 ) {
29
$q
= new DBQuery ;
$q−>addTable ( ’ p r o j e c t s ’ ) ;
31
$q−>addQuery ( ’ p r o j e c t t a r g e t b u d g e t , p r o j e c t s t a r t d a t e , p r o j e c t e n d d a t e ,
project name ’ ) ;
$q−>addWhere ( ’ p r o j e c t n a m e = ’ . $project name ) ;
33
$res =& $q−>exec ( ) ;
35
$row−>planned budget = $res−>f i e l d s [ ’ p r o j e c t t a r g e t b u d g e t ’ ] ;
$row−>p r o j e c t p l a n n e d s t a r t d a t e = $res−>f i e l d s [ ’ p r o j e c t s t a r t d a t e ’ ] ;
37
$row−>p r o j e c t p l a n n e d e n d d a t e = $res−>f i e l d s [ ’ p r o j e c t e n d d a t e ’ ] ;
$row−>p r o j e c t n a m e = $res−>f i e l d s [ ’ p r o j e c t n a m e ’ ] ;
39
$ s t a r t d a t e = new CDate ( $row−>p r o j e c t p l a n n e d s t a r t d a t e ) ;
79
41
$end date = i n t v a l ( $row−>p r o j e c t p l a n n e d e n d d a t e ) ? new CDate ( $row−>
project planned end date ) : n u l l ;
43
$meeting date = n u l l ;
45
$actual start date =
null ;
47
$actual end date =
null ;
49
echo $res−>f i e l d s [ ’ p r o j e c t s t a r t d a t e ’ ] ;
51
} else {
53
/ / f o r m a t dates
$ d f = $AppUI−>g e t P r e f ( ’SHDATEFORMAT ’ ) ;
55
$ s t a r t d a t e = new CDate ( $row−>p r o j e c t p l a n n e d s t a r t d a t e ) ;
57
$end date = i n t v a l ( $row−>p r o j e c t p l a n n e d e n d d a t e ) ? new CDate ( $row−>
project planned end date ) : n u l l ;
59
$meeting date = i n t v a l ( $row−>p r o j e c t m e e t i n g d a t e ) ? new CDate ( $row−>
project meeting date ) : null ;
61
$ a c t u a l s t a r t d a t e = i n t v a l ( $row−>p r o j e c t s t a r t d a t e ) ? new CDate ( $row−>
project start date ) : null ;
63
$ a c t u a l e n d d a t e = i n t v a l ( $row−>p r o j e c t e n d d a t e ) ? new CDate ( $row−>
project end date ) : null ;
65
$ p a r t i c i p a n t s = $row−>p a r t i c i p a n t s ;
67
}
69
/ / setup t h e t i t l e b l o c k
$ t t l = $pma id > 0 ? ’ E d i t Post Mortem ’ :
’New Post Mortem ’ ;
71
$ t i t l e B l o c k = new C T i t l e B l o c k ( $ t t l ,
73
’ c l o s e d . png ’ , $m, ”$m. $a ” ) ;
$ t i t l e B l o c k −>addCrumb ( ’ ?m= c l o s u r e ’ , ’ p o s t mortem l i s t ’ ) ;
i f ( $pma id ! = 0 ) {
$ t i t l e B l o c k −>addCrumb ( ’ ?m= c l o s u r e&amp ; a=view&amp ; pma id= ’ . $pma id ,
75
t h i s p o s t mortem ’ ) ;
}
77
$ t i t l e B l o c k −>show ( ) ;
’ view
80
79
/ ∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ D i s p l a y ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗ /
r e q u i r e o n c e ( DP BASE DIR .
’ / c l a s s e s / CustomFields . c l a s s . php ’ ) ;
$ c u s t o m f i e l d s = New CustomFields ( $m, $a , $row−>pma id ,
81
$q
83
’ edit ’ ) ;
= new DBQuery ;
$q−>addQuery ( ’ p r o j e c t n a m e ’ ) ;
85
$p = $q−>l o a d L i s t ( ) ;
$projects = array ( ) ;
87
$i = 0;
f o r e a c h ( $p as $ p r o j e c t ) {
89
$ p r o j e c t s [ $ p r o j e c t [ ’ project name ’ ] ] = $ p r o j e c t [ ’
project name ’ ] ;
91
}
93
$q
= new DBQuery ;
$q−>addTable ( ’ c o n t a c t s ’ ) ;
$q−>addQuery ( ’ c o n t a c t f i r s t n a m e , c o n t a c t l a s t n a m e ’ ) ;
95
$res =& $q−>exec ( ) ;
97
$pieces = explode ( ” , ” , $ p a r t i c i p a n t s ) ;
99
?>
<form name= ” e d i t F r m ” a c t i o n = ” ?m= c l o s u r e ” method= ” p o s t ”>
101


” />
103
105
<?php echo $AppUI
−> ( ’ Meeting S e t t i n g s ’ ) ?>
107
<t a b l e a l i g n = l e f t w i d t h = ’100% ’ b o r d e r = ’ 0 ’ c e l l p a d d i n g = ’ 2 ’ c e l l s p a c i n g = ’ 1 ’
c l a s s = ’ s t d ’>
<t r > <t d a l i g n = ’ l e f t ’>Meeting P a r t i c i p a n t s </ td ></ t r >
109
<t r >
111
<t d a l i g n = ’ l e f t ’ w i d t h = ’5% ’>
<s e l e c t m u l t i p l e s i z e = ” 10 ” name= ” l i s t 1 ” s t y l e = ” w i d t h :150 ”>
113
<?php
115
$i = 0;
f o r ( $res ; ! $res−>EOF; $res−>MoveNext ( ) ) {
81
$ c o n t a c t f i r s t n a m e = $res−>f i e l d s [ ’ c o n t a c t f i r s t n a m e ’ ] ;
117
i f ( a r r a y s e a r c h ( $ c o n t a c t f i r s t n a m e , $pieces ) === f a l s e ) {
119
?>
<o p t i o n v a l u e = <?php echo $ i ;?> >
<?php echo $ c o n t a c t f i r s t n a m e ; ?>
121
</ o p t i o n >
123
<?php
$ i ++;
}
125
}
127
?>
</ s e l e c t >
129
</ td>
<t d a l i g n = ’ l e f t ’>
131

>” />
133
<s e l e c t m u l t i p l e s i z e = ” 10 ” v a l i g n = ” l e f t ” name= ” l i s t 2 ” s t y l e = ” w i d t h :150 ”>
135
<?php
$p2 = ” ” ;
137
$ l i m i t = count ( $pieces ) ;
139
$i = 0;
i f ( $ l i m i t > 1) {
141
f o r ( $ i = 0 ; $ i < $ l i m i t ; $ i ++) {
$p2
143
= $p2 . $pieces [ $ i ] ;
?>
<?php echo $pieces [ $ i ] ; ?>
145
</ o p t i o n >
147
<?php
}
149
} else {
i f ( $participants ){
?>
151
<?php echo $ p a r t i c i p a n t s ; ?>
153
</ o p t i o n >
<?php
155
}
157
}
82
?>
159
</ s e l e c t >
</ td>
161
163
</ t r >
<t r >
<t d a l i g n = ” l e f t ” ><?php echo $AppUI−> ( ’ Meeting Date ’ ) ?></td>
<t d a l i g n = ” l e f t ” >
165
f o r m a t ( FMT TIMESTAMP DATE ) :
’ ’) ;
?>” />
<!−− f o r m a t ( FMT TIMESTAMP DATE ) −−>
f o r m a t ( $ d f ) :
’ ’ ) ; ?>” d i s a b l e d = ”
d i s a b l e d ” />
171
<a h r e f = ” # ” o n c l i c k = ” popCalendar ( ’ m e e t i n g d a t e ’ , ’ m e e t i n g d a t e ’ ) ; ”
>
<img s r c = ” . / images / c a l e n d a r . g i f ” w i d t h = ” 24 ” h e i g h t = ” 12 ” a l t = ” {
173
d P t r a n s l a t e word = ’ Calendar ’ } ” b o r d e r = ” 0 ” />
</a>
</ td>
175
</ t r >
177
179
</ t a b l e >
<?php echo $AppUI
−> ( ’ P r o j e c t Summary ’ ) ?>
181
<t a b l e a l i g n = l e f t w i d t h = ’100% ’ b o r d e r = ’ 0 ’ c e l l p a d d i n g = ’ 2 ’ c e l l s p a c i n g = ’ 1 ’
c l a s s = ’ s t d ’>
<t d a l i g n = ’ r i g h t ’><?php echo $AppUI−> ( ’ P r o j e c t Name ’ ) ?></td>
183
<t d nowrap= ” nowrap ”>
185
<?php
echo a r r a y S e l e c t ( $ p r o j e c t s ,
’ p r o j e c t n a m e ’ , ’ s i z e = ” 1 ” c l a s s =” t e x t ” ’ , $row−>
project name , t r u e ) ; ?>
187
189
191
</ td>
<t r >
<t d a l i g n = ” r i g h t ” nowrap= ” nowrap ”><?php echo $AppUI−> ( ’ P r o j e c t
83
Planned S t a r t Date ’ ) ?></td>
<i n p u t t y p e = ” hidden ” name= ” p r o j e c t p l a n n e d s t a r t d a t e ” i d = ”
193
p r o j e c t p l a n n e d s t a r t d a t e ” v a l u e = ”<?php
echo ( ( $ s t a r t d a t e ) ? $ s t a r t d a t e −>f o r m a t ( FMT TIMESTAMP DATE ) :
’ ’ ) ; ?>”
/>
195
f o r m a t ( $ d f ) :
’ ’ ) ; ?> ” d i s a b l e d = ”
d i s a b l e d ” />
199
<a h r e f = ” # ” o n c l i c k = ” popCalendar ( ’ p l a n n e d s t a r t d a t e ’ , ’
p l a n n e d s t a r t d a t e ’ ) ; ”>
201
</a>
</ td>
203
<t d a l i g n = ” r i g h t ” nowrap= ” nowrap ”><?php echo $AppUI−> ( ’ P r o j e c t S t a r t
Date ’ ) ?></td>
205
<i n p u t t y p e = ” hidden ” name= ” p r o j e c t s t a r t d a t e ” i d = ”
p r o j e c t s t a r t d a t e ” v a l u e = ”<?php
207
echo ( ( $ a c t u a l s t a r t d a t e ) ? $ a c t u a l s t a r t d a t e −>f o r m a t (
FMT TIMESTAMP DATE ) :
’ ’ ) ; ?> ” />
209
f o r m a t ( $ d f ) :
’ ’ ) ;?> ”
d i s a b l e d = ” d i s a b l e d ” />
211
<a h r e f = ” # ” o n c l i c k = ” popCalendar ( ’ s t a r t d a t e ’ , ’ s t a r t d a t e ’ ) ; ”>
213
</a>
</ td>
215
</ t r >
217
<t r >
219
<t d a l i g n = ” r i g h t ” nowrap= ” nowrap ”><?php echo $AppUI−> ( ’ P r o j e c t
Planned End Date ’ ) ?></td>
84
221
f o r m a t ( FMT TIMESTAMP DATE ) :
’ ’ ) ; ?> ” />
f o r m a t ( $ d f ) :
’ ’ ) ; ?>” d i s a b l e d = ” d i s a b l e d ”
/>
227
<a h r e f = ” # ” o n c l i c k = ” popCalendar ( ’ p l a n n e d e n d d a t e ’ , ’
p l a n n e d e n d d a t e ’ ) ; ”>
229
</a>
</ td>
231
233
<t d a l i g n = ” r i g h t ” nowrap= ” nowrap ”><?php echo $AppUI−> ( ’ P r o j e c t End
Date ’ ) ;?></ td>
f o r m a t ( FMT TIMESTAMP DATE ) :
’ ’ ) ; ?>” />
237
f o r m a t ( $ d f ) :
’ ’ ) ;?> ”
d i s a b l e d = ” d i s a b l e d ” />
<a h r e f = ” # ” o n c l i c k = ” popCalendar ( ’ end date ’ , ’ end date ’ ) ; ”>
241
</a>
243
</ td>
245
</ t r >
247
<t r >
249
<t d a l i g n = ’ r i g h t ’><?php echo $AppUI−> ( ’ P r o j e c t Planned Budget ’ ) ;?></ td>
<td>
planned budget ) ; ?>” /></ td>
251
<t d a l i g n = ’ r i g h t ’><?php echo $AppUI−> ( ’ P r o j e c t Budget ’ ) ;?></ td>
85
<td>
planned budget ) ; ?>” /></ td>
253
</ t r >
255
</ t a b l e >
257
<?php echo
$AppUI−> ( ’ Lessons Learned ’ ) ;?>
<t a b l e c e l l s p a c i n g = ” 1 ” c e l l p a d d i n g = ” 1 ” b o r d e r = ” 0 ” w i d t h = ” 100% ” c l a s s = ” s t d ”>
259
<t r ><t d a l i g n = ’ r i g h t ’><?php echo $AppUI−> ( ’ P r o j e c t S t r e n g t h s ’ ) ?></td>
<td><t e x t a r e a name= ’ p r o j e c t s t r e n g t h ’ c o l s =80 rows=8 ><?php echo
dPformSafe ( $row−>p r o j e c t s t r e n g t h ) ; ?></ t e x t a r e a >
261
L i s t here ( each t o p i c w i t h ’ ∗ ’ ) t e c h n o l o g i e s , processes , IDEs o r
whatever t e c n i q u e s , t o o l s o r s e r v i c e s t h a t worked o u t f o r you i n t h i s
project
</ td>
263
<t r ><t d a l i g n = ’ r i g h t ’><?php echo $AppUI−> ( ’ P r o j e c t Weaknesses ’ ) ;?></ td
>
<td><t e x t a r e a name= ’ p r o j e c t w e a k n e s s e s ’ c o l s =80 rows=8 ><?php echo
dPformSafe ( $row−>weaknesses ) ; ?></ t e x t a r e a >
265
L i s t here ( each t o p i c w i t h ’ ∗ ’ ) t e c h n o l o g i e s , processes , IDEs o r
whatever t e c n i q u e s , t o o l s o r s e r v i c e s t h a t d i d n o t worked o u t f o r you
in this project
<t r ><t d a l i g n = ’ r i g h t ’><?php echo $AppUI−> ( ’ Improvement Suggestions ’ )
;?></ td>
267
<td><t e x t a r e a name= ’ improvement suggestions ’ c o l s =80 rows=8 ><?php echo
dPformSafe ( $row−>improvement suggestions ) ; ?></ t e x t a r e a >
L i s t here ( each t o p i c w i t h ’ ∗ ’ ) t h e aspects o f t h e p r o j e c t t h a t need t o
be improved
269
<t r ><t d a l i g n = ’ r i g h t ’><?php echo $AppUI−> ( ’ Conclusions ’ ) ;?></ td>
<td><t e x t a r e a name= ’ c o n c l u s i o n s ’ c o l s =80 rows=8 ><?php echo dPformSafe (
$row−>c o n c l u s i o n s ) ; ?></ t e x t a r e a >
271
General c o n c l u s i o n s about t h e p r o j e c t
273
</ td>
</ t r >
275
p a r t i c i p a n t s ) ; ?> ”> 
</ t a b l e >
277
279
<t a b l e c e l l s p a c i n g = ” 1 ” c e l l p a d d i n g = ” 1 ” b o r d e r = ” 0 ” w i d t h = ” 100% ”>
86
281
<t r >
<td>
 ( ’ back ’ ) ;?> ”
283
c l a s s = ” b u t t o n ” o n c l i c k = ” j a v a s c r i p t : h i s t o r y . back ( −1) ; ” />
</ td>
285
<t d a l i g n = ” r i g h t ”>
 ( ’ submit ’ ) ;?> ”
287
c l a s s = ” b u t t o n ” o n c l i c k = ” move ( e d i t F r m . l i s t 1 , e d i t F r m . l i s t 2 ) ; s u b m i t I t H e r e
( ) ; ” />
</ td>
289
291
</ t r >
</ t a b l e >
293
</ form>
295
<!−− i m p o r t t h e c a l e n d a r s c r i p t −−>
< s c r i p t t y p e = ” t e x t / j a v a s c r i p t ” s r c = ”<?php echo DP BASE URL;? >/ l i b / c a l e n d a r /
c a l e n d a r . j s ” ></ s c r i p t >
297
<!−− i m p o r t t h e language module −−>
< s c r i p t t y p e = ” t e x t / j a v a s c r i p t ” s r c = ”<?php echo DP BASE URL;? >/ l i b / c a l e n d a r /
l a n g / calendar −<?php echo $AppUI−>u s e r l o c a l e ; ?>. j s ” ></ s c r i p t >
299
< s c r i p t t y p e = ” t e x t / j a v a s c r i p t ” language= ” j a v a s c r i p t ”>
301
function setShort ( ) {
303
v a r f = document . e d i t F r m ;
var x = 10;
305
i f ( f . p r o j e c t n a m e . v a l u e . l e n g t h < 11) {
x = f . project name . value . length ;
307
}
i f ( f . p r o j e c t s h o r t n a m e . v a l u e . l e n g t h == 0 ) {
f . project short name . value = f . project name . value . substr (0 , x ) ;
309
}
311
}
313
var calendarField = ’ ’ ;
v a r calWin = n u l l ;
315
f u n c t i o n popCalendar ( f i e l d ) {
317
calendarField = f i e l d ;
i d a t e = e v a l ( ’ document . e d i t F r m . p r o j e c t ’ + f i e l d + ’ . v a l u e ’ ) ;
319
window . open ( ’ i n d e x . php?m= p u b l i c &a= c a l e n d a r& d i a l o g =1& c a l l b a c k = s e t C a l e n d a r&
date= ’ + i d a t e ,
’ c a l w i n ’ , ’ w i d t h =280 , h e i g h t =250 , s c r o l l b a r s =no ’ ) ;
87
}
321
/∗ ∗
323
∗ @param s t r i n g I n p u t date i n t h e f o r m a t YYYYMMDD
∗ @param s t r i n g Formatted date
325
∗/
f u n c t i o n setCalendar ( idate , f dat e ) {
f l d d a t e = e v a l ( ’ document . e d i t F r m . p r o j e c t ’ + c a l e n d a r F i e l d ) ;
327
f l d f d a t e = e v a l ( ’ document . e d i t F r m . ’ + c a l e n d a r F i e l d ) ;
f l d d a t e . value = i d a t e ;
329
f l d f d a t e . value = fdate ;
331
/ / s e t end date a u t o m a t i c a l l y w i t h s t a r t date i f
s t a r t date i s a f t e r end
date
i f ( c a l e n d a r F i e l d == ’ s t a r t d a t e ’ ) {
333
i f ( document . e d i t F r m . end date . v a l u e < i d a t e ) {
document . e d i t F r m . p r o j e c t e n d d a t e . v a l u e = i d a t e ;
335
document . e d i t F r m . end date . v a l u e = f d a t e ;
}
337
}
339
}
341
function submitItHere ( ) {
v a r f = document . e d i t F r m ;
f . submit ( ) ;
343
}
345
347
f u n c t i o n move ( MenuOrigem , MenuDestino ) {
349
v a r arrMenuOrigem = new A r r a y ( ) ;
351
v a r arrMenuDestino = new A r r a y ( ) ;
353
v a r arrLookup = new A r r a y ( ) ;
355
var i ;
357
var s t r i n g T o P e r s i s t = ” ” ;
359
f o r ( i = 0 ; i < MenuDestino . o p t i o n s . l e n g t h ; i ++) {
361
arrLookup [ MenuDestino . o p t i o n s [ i ] . t e x t ] = MenuDestino . o p t i o n s [ i ] .
88
value ;
arrMenuDestino [ i ] = MenuDestino . o p t i o n s [ i ] . t e x t ;
363
}
365
var fLength = 0;
367
v a r t L e n g t h = arrMenuDestino . l e n g t h ;
369
f o r ( i = 0 ; i < MenuOrigem . o p t i o n s . l e n g t h ; i ++) {
371
arrLookup [ MenuOrigem . o p t i o n s [ i ] . t e x t ] = MenuOrigem . o p t i o n s [ i ] . v a l u e
;
373
i f ( MenuOrigem . o p t i o n s [ i ] . s e l e c t e d && MenuOrigem . o p t i o n s [ i ] . v a l u e
!= ” ” ) {
375
arrMenuDestino [ t L e n g t h ] = MenuOrigem . o p t i o n s [ i ] . t e x t ;
t L e n g t h ++;
377
379
}
381
else {
383
arrMenuOrigem [ f L e n g t h ] = MenuOrigem . o p t i o n s [ i ] . t e x t ;
385
f L e n g t h ++;
}
387
389
}
391
arrMenuOrigem . s o r t ( ) ;
393
arrMenuDestino . s o r t ( ) ;
395
MenuOrigem . l e n g t h = 0 ;
397
MenuDestino . l e n g t h = 0 ;
399
var c ;
401
f o r ( c = 0 ; c < arrMenuOrigem . l e n g t h ; c ++) {
89
403
v a r no = new Option ( ) ;
405
no . v a l u e = arrLookup [ arrMenuOrigem [ c ] ] ;
407
no . t e x t = arrMenuOrigem [ c ] ;
409
MenuOrigem [ c ] = no ;
411
}
413
f o r ( c = 0 ; c < arrMenuDestino . l e n g t h ; c ++) {
415
v a r no = new Option ( ) ;
417
no . v a l u e = arrLookup [ arrMenuDestino [ c ] ] ;
419
no . t e x t = arrMenuDestino [ c ] ;
421
s t r i n g T o P e r s i s t += arrMenuDestino [ c ] ;
423
i f ( c ! = arrMenuDestino . l e n g t h −1)
s t r i n g T o P e r s i s t += ” , ” ;
425
MenuDestino [ c ] = no ;
427
}
429
document . getElementById ( ’ p a r t i c i p a n t s ’ ) . v a l u e = s t r i n g T o P e r s i s t ;
431
}
433
</ s c r i p t >
90
closure.class.php
<?php
2
if
directly ’ ) ;
4
}
6
r e q u i r e o n c e $AppUI−>getSystemClass ( ’ dp ’ ) ;
r e q u i r e o n c e $AppUI−>getSystemClass ( ’ query ’ ) ;
8
c l a s s CClosure extends CDpObject {
v a r $pma id = n u l l ;
10
v a r $project name = n u l l ;
var $ p r o j e c t s t a r t d a t e = n u l l ;
12
var $project end date = n u l l ;
var $ p r o j e c t p l a n n e d s t a r t d a t e = n u l l ;
14
var $project planned end date = n u l l ;
var $project meeting date = n u l l ;
16
v a r $planned budget = 0 ;
v a r $budget = 0 ;
18
var $ p a r t i c i p a n t s = n u l l ;
var $ p r o j e c t s t r e n g t h = n u l l ;
20
v a r $pro ject weaknesses = n u l l ;
v a r $improvement suggestions = n u l l ;
22
var $conclusions = n u l l ;
24
f u n c t i o n CClosure ( ) {
p a r e n t : : CDpObject ( ’ p o s t m o r t e m a n a l y s i s ’ , ’ pma id ’ ) ;
26
}
28
f u n c t i o n load ( $oid= n u l l , $ s t r i p = t r u e ) {
$ r e s u l t = p a r e n t : : l o a d ( $oid , $ s t r i p ) ;
30
i f ( $ r e s u l t && $ o i d ) {
$q = new DBQuery ;
32
$q−>addTable ( ’ p o s t m o r t e m a n a l y s i s ’ , ’pma ’ ) ;
34
$q−>addJoin ( ’ p r o j e c t s ’ , ’ p1 ’ , ’ p1 . p r o j e c t n a m e = pma . p r o j e c t n a m e ’ ) ;
i f ( $oid != n u l l )
36
$q−>addWhere ( ” p r o j e c t i d = $ o i d ” ) ;
}
38
return $result ;
40
42
}
function store ( ) {
91
$ t h i s −>d P T r i m A l l ( ) ;
44
$msg = $ t h i s −>check ( ) ;
i f ( $msg ) {
46
r e t u r n g e t c l a s s ( $ t h i s ) . ” : : s t o r e −check f a i l e d − $msg ” ;
48
}
50
$ d e t a i l s [ ’ p r o j e c t n a m e ’ ] = $ t h i s −>p r o j e c t n a m e ;
$ d e t a i l s [ ’ pma id ’ ] = $ t h i s −>pma id ;
i f ( $ t h i s −>pma id ) {
52
$ r e t = db updateObject ( ’ p o s t m o r t e m a n a l y s i s ’ , $ t h i s ,
’ pma id ’ , t r u e
);
$ d e t a i l s [ ’ changes ’ ] = $ r e t ;
54
a d d H i s t o r y ( ’ p o s t m o r t e m a n a l y s i s ’ , $ t h i s −>pma id ,
’ update ’ , $ d e t a i l s )
;
}
56
else {
$ret = db insertObject ( ’ post mortem analysis ’ , $this ,
58
a d d H i s t o r y ( ’ p o s t m o r t e m a n a l y s i s ’ , $ t h i s −>pma id ,
’ pma id ’ ) ;
’ add ’ , $ d e t a i l s ) ;
}
60
i f ( ! $ret ) {
62
r e t u r n g e t c l a s s ( $ t h i s ) . ” : : s t o r e f a i l e d ” . d b e r r o r ( ) ;
}
64
else {
r e t u r n NULL ;
66
}
68
}
70
f u n c t i o n canDelete ( &$msg , $ o i d = n u l l ) {
/ / TODO: check i f user p e r m i s s i o n s are c o n s i d e r e d when d e l e t i n g a
project
g l o b a l $AppUI ;
72
$perms =& $AppUI−>a c l ( ) ;
74
r e t u r n $perms−>checkModuleItem ( ’ c l o s u r e ’ , ’ d e l e t e ’ , $ o i d ) ;
76
}
78
function delete ( ) {
$ t h i s −>l o a d ( $ t h i s −>p r o j e c t i d ) ;
80
$ d e t a i l s [ ’ name ’ ] = $ t h i s −>p r o j e c t n a m e ;
a d d H i s t o r y ( ’ p o s t m o r t e m a n a l y s i s ’ , $ t h i s −>project name ,
$details ) ;
’ delete ’ ,
92
82
$q = new DBQuery ;
$q−>s e t D e l e t e ( ’ p o s t m o r t e m a n a l y s i s ’ ) ;
84
$q−>addWhere ( ’ pma id = ’ . $ t h i s −>pma id ) ;
86
$ r e s u l t = ( ( ! $q−>exec ( ) ) ? d b e r r o r ( ) : NULL ) ;
$q−>c l e a r ( ) ;
88
return $result ;
}
90
92
}
94
?>
93
companies tab.experience factory.php
<?php / ∗ PROJECTS $ I d : companies tab . view . a c t i v e p r o j e c t s . php 4779
2007−02−21 1 4 : 5 3 : 2 8Z cyberhorse $ ∗ /
2
if
4
}
6
/∗ ∗
directly ’ ) ;
∗ Companies : View A c t i v e P r o j e c t s sub−t a b l e
∗/
8
g l o b a l $AppUI , $company id , $ p s t a t u s , $m;
10
$ p s t a t u s = dPgetSysVal ( ’ P r o j e c t S t a t u s ’ ) ;
12
i f ( $ s o r t == ’ p r o j e c t p r i o r i t y ’ ) {
$ s o r t . = ’ DESC ’ ;
14
}
16
18
$page = i s s e t ($ REQUEST [ ’ page ’ ] ) ?$ REQUEST [ ’ page ’ ] : 1 ;
20
$q
= new DBQuery ;
22
$q−>addQuery ( ’ d i s t i n c t pma . project name , p r o j e c t i d , pma id , p r o j e c t s t a t u s
,
pma . p r o j e c t s t a r t d a t e , pma . p r o j e c t e n d d a t e , p r o j e c t m e e t i n g d a t e ’ ) ;
24
$q−>addJoin ( ’ p r o j e c t s ’ , ’ p ’ , ’ p . p r o j e c t n a m e = pma . p r o j e c t n a m e ’ ) ;
$q−>addWhere ( ’ p . project company = ’ . $company id ) ;
26
$q−>addOrder ( $ s o r t ) ;
$rows = $q−>l o a d L i s t ( ) ;
28
30
?>
32
<t a b l e w i d t h = ” 100% ” b o r d e r = ” 0 ” c e l l p a d d i n g = ” 2 ” c e l l s p a c i n g = ” 1 ” c l a s s = ” t b l ”>
<t r >
34
<t h w i d t h = ” 12 ” />
<t h w i d t h = ”30%”><?php echo $AppUI−> ( ’ Post Mortem Records by p r o j e c t ’ ) ;
?></th>
36
<t h w i d t h = ”20%”><?php echo $AppUI−> ( ’ P r o j e c t Meeting Date ’ ) ; ?></th>
<t h w i d t h = ”20%”><?php echo $AppUI−> ( ’ P r o j e c t S t a r t Date ’ ) ; ?></th>
38
<t h w i d t h = ”20%”><?php echo $AppUI−> ( ’ P r o j e c t End Date ’ ) ;?></ th>
<t h w i d t h = ”10%”><?php echo $AppUI−> ( ’ P r o j e c t S t a t u s ’ ) ;?></ th>
94
40
</ t r >
<?php f o r e a c h ( $rows as $p ) {
$meeting date = i n t v a l ( $p [ ’ p r o j e c t m e e t i n g d a t e ’ ] ) ? new CDate ( $p [ ’
42
project meeting date ’ ] ) : null ;
$ s t a r t d a t e = i n t v a l ( $p [ ’ p r o j e c t s t a r t d a t e ’ ] ) ? new CDate ( $p [ ’
project start date ’ ]) : null ;
$end date = i n t v a l ( $p [ ’ p r o j e c t e n d d a t e ’ ] ) ? new CDate ( $p [ ’
44
project end date ’ ] ) : null ;
?>
46
<t r >
<t d w i d t h = ” 12 ” s t y l e = ” background−c o l o r : # { $row . p r o j e c t c o l o r i d e n t i f i e r }
”>
<a h r e f = ” ?m= c l o s u r e&amp ; a= a d d e d i t&amp ; pma id=<?php echo $p
48
[ ’ pma id ’ ] ; ? > ”>
<img s r c = ” . / images / i c o n s / p e n c i l . g i f ” a l t = ” E d i t p o s t
mortem r e c o r d ” ></a>
50
</ td>
<td> <a h r e f = ” ?m= c l o s u r e&amp ; a=view&amp ; pma id=<?php echo $p [ ’ pma id ’ ] ; ? >
”> <?php echo $p [ ’ p r o j e c t n a m e ’ ] ; ?> <a/> </ td>
52
<td> <?php echo $meeting date ? $meeting date−>f o r m a t ( $ d f ) :
’ ’ ; ?></td>
54
<td> <?php echo $ s t a r t d a t e ? $ s t a r t d a t e −>f o r m a t ( $ d f ) :
’ ’ ; ?></td>
56
<td> <?php echo $end date ? $end date−>f o r m a t ( $ d f ) :
58
<td> <?php echo $p [ ’ p r o j e c t s t a t u s ’ ] ; ?></td>
60
</ t r >
<?php } ?>
62
</ t a b l e >
’ ’ ; ?></td>
95
do closure aed.php
<?php / ∗ PROJECTS $ I d : d o p r o j e c t a e d . php 4779 2007−02−21 1 4 : 5 3 : 2 8Z
cyberhorse $ ∗ /
2
if
4
}
6
$ o b j = new CClosure ( ) ;
directly ’ ) ;
$msg = ’ ’ ;
8
( ! $obj−>b i n d ( $ POST ) ) {
if
$AppUI−>setMsg ( $obj−>g e t E r r o r ( ) , UI MSG ERROR ) ;
10
12
}
14
r e q u i r e o n c e ( DP BASE DIR .
’ / c l a s s e s / CustomFields . c l a s s . php ’ ) ;
16
$ d e l = dPgetParam ( $ POST ,
’ del ’ , 0 ) ;
18
/ / prepare ( and t r a n s l a t e ) t h e module name ready f o r t h e s u f f i x
i f ( $del ) {
20
$ p r o j e c t i d = dPgetParam ( $ POST ,
’ pma id ’ , 0 ) ;
$canDelete = $obj−>canDelete ( $msg , $pma id ) ;
22
if
( ! $canDelete ) {
$AppUI−>setMsg ( $msg , UI MSG ERROR ) ;
24
}
26
if
( ( $msg = $obj−>d e l e t e ( ) ) ) {
28
} else {
$AppUI−>setMsg ( ’ Post Mortem d e l e t e d ’ , UI MSG ALERT ) ;
30
$AppUI−>r e d i r e c t ( ’m= c l o s u r e ’ ) ;
32
}
} else {
34
if
( ( $msg = $obj−>s t o r e ( ) ) ) {
36
} else {
$isNotNew = @$ POST [ ’ pma id ’ ] ;
38
$ c u s t o m f i e l d s = New CustomFields ( $m,
’ a d d e d i t ’ , $obj−>pma id , ” e d i t ”
);
$ c u s t o m f i e l d s −>b i n d ( $ POST ) ;
40
$ s q l = $obj−>s t o r e ( $obj−>pma id ) ; / / S t o r e Custom F i e l d s
96
$AppUI−>setMsg ( $isNotNew ? ’ Post Mortem updated ’ :
42
i n s e r t e d ’ , UI MSG OK ) ;
}
44
}
46
?>
’ Post Mortem
97
index.php
<?php
2
if
4
}
6
$AppUI−>savePlace ( ) ;
8
$perms = $AppUI−>a c l ( ) ;
directly ’ ) ;
$ c a n E d i t = $perms−>checkModule ($m, ” e d i t ” ) ;
10
$ t i t l e B l o c k = new C T i t l e B l o c k ( ’ Closure ’ , ’ c l o s e d . png ’ , $m, ”$m. $a ” ) ;
12
i f ( $canEdit ) {
$ t i t l e B l o c k −>a d d C e l l (
’ ( ’ new p o s t
14
mortem a n a l y s i s ’ ) . ’ ”> ’ , ’ ’ ,
’<form a c t i o n =”?m= c l o s u r e&a= a d d e d i t ” method =” p o s t ”> ’ , ’ </ form> ’
);
16
}
18
$ t i t l e B l o c k −>show ( ) ;
20
$q = new DBQuery ;
22
$q−>addQuery ( ’ d i s t i n c t pma . project name , pma . pma id ,
24
pma . p r o j e c t s t a r t d a t e , pma . p r o j e c t e n d d a t e , pma . p r o j e c t m e e t i n g d a t e ’ ) ;
26
$rows = $q−>l o a d L i s t ( ) ;
28
?>
30
<t r >
32
<t h w i d t h = ”1%” ></th>
<t h w i d t h = ” 10 ”><?php echo $AppUI−> ( ’ P r o j e c t Name ’ ) ; ?></th>
34
<t h w i d t h = ” 10 ”><?php echo $AppUI−> ( ’ P r o j e c t Meeting Date ’ ) ; ?></th>
<t h w i d t h = ” 10 ”><?php echo $AppUI−> ( ’ P r o j e c t S t a r t Date ’ ) ; ?></th>
36
<t h w i d t h = ” 10 ”><?php echo $AppUI−> ( ’ P r o j e c t End Date ’ ) ;?></ th>
</ t r >
38
40
$ s t a r t d a t e = i n t v a l ( $p [ ’ p r o j e c t s t a r t d a t e ’ ] ) ? new CDate ( $p [ ’
98
project start date ’ ]) : null ;
$end date = i n t v a l ( $p [ ’ p r o j e c t e n d d a t e ’ ] ) ? new CDate ( $p [ ’
project end date ’ ] ) : null ;
42
?>
<t r >
44
<td> <a h r e f = ” ?m= c l o s u r e&amp ; a= a d d e d i t&amp ; pma id=<?php echo $p [ ’ pma id
’ ] ; ? > ”><img s r c = ” . / images / i c o n s / p e n c i l . g i f ” a l t = ” E d i t p o s t mortem
a n a l y s i s ” </a> </ td>
46
”><?php echo $p [ ’ p r o j e c t n a m e ’ ] ; ?></a> </ td>
48
<td> <?php echo $meeting date ? $meeting date−>f o r m a t ( $ d f ) :
50
<td> <?php echo $ s t a r t d a t e ? $ s t a r t d a t e −>f o r m a t ( $ d f ) :
52
<td> <?php echo $end date ? $end date−>f o r m a t ( $ d f ) :
</ t r >
54
<?php } ?>
</ t a b l e >
’ ’ ; ?></td>
’ ’ ; ?></td>
’ ’ ; ?></td>
99
projects tab.post mortem analysis.php
1
<?php / ∗ PROJECTS $ I d : companies tab . view . a c t i v e p r o j e c t s . php 4779
2007−02−21 1 4 : 5 3 : 2 8Z cyberhorse $ ∗ /
if
3
directly ’ ) ;
}
5
g l o b a l $AppUI , $ p s t a t u s , $ t p l , $m;
7
r e q u i r e o n c e ( $AppUI−>getModuleClass ( ’ f i l e s ’ ) ) ;
9
$ p s t a t u s = dPgetSysVal ( ’ P r o j e c t S t a t u s ’ ) ;
11
$ p r o j e c t i d = $ GET [ ’ p r o j e c t i d ’ ] ;
13
$ s o r t = dPgetParam ( $ GET ,
’ o r d e r b y ’ , ’ pma id ’ ) ;
i f ( $ s o r t == ’ pma id ’ ) {
$ s o r t . = ’ DESC ’ ;
15
}
17
19
$page = i s s e t ($ REQUEST [ ’ page ’ ] ) ?$ REQUEST [ ’ page ’ ] : 1 ;
21
$q
= new DBQuery ;
23
$q−>addQuery ( ’ pma id , pma . project name , p r o j e c t m e e t i n g d a t e , p a r t i c i p a n t s ’
);
$q−>addJoin ( ’ p r o j e c t s ’ , ’ p ’ , ’ p . p r o j e c t n a m e = pma . p r o j e c t n a m e ’ ) ;
25
$q−>addWhere ( ’ p . p r o j e c t i d = ’ . $ p r o j e c t i d ) ;
$q−>addOrder ( $ s o r t ) ;
27
$rows = $q−>l o a d L i s t ( ) ;
29
$q−>addQuery ( ’ count ( ∗ ) ’ ) ;
31
$q−>addWhere ( ’ p r o j e c t i d = ’ . $ p r o j e c t i d ) ;
$count rows = $q−>l o a d R e s u l t ( ) ;
33
$q
35
= new DBQuery ;
37
$q−>addWhere ( ’ p r o j e c t i d = ’ . $ p r o j e c t i d ) ;
$res =& $q−>exec ( ) ;
39
$project name = $res−>f i e l d s [ ’ p r o j e c t n a m e ’ ] ;
100
41
43
?>
45
<t r >
47
<th> </ th>
<t h w i d t h = ”50%”><?php echo $AppUI−> ( ’ P r o j e c t Meeting Date ’ ) ; ?></th>
49
<t h w i d t h = ”50%”><?php echo $AppUI−> ( ’ P a r t i c i p a n t s ’ ) ; ?></th>
</ t r >
51
53
?>
55
<t r >
<td><a h r e f = ” ?m= c l o s u r e&amp ; a= a d d e d i t&amp ; pma id=<?php echo $p [ ’ pma id
’ ] ; ? > ”><img s r c = ” . / images / i c o n s / p e n c i l . g i f ” a l t = ” E d i t p o s t mortem
a n a l y s i s ” ></a> </ td>
57
”>
<?php echo $meeting date ? $meeting date−>f o r m a t ( $ d f ) :
’ ’ ; ?> </a></td>
59
<td> <?php echo $p [ ’ p a r t i c i p a n t s ’ ] ; ?></td>
61
</ t r >
63
<?php } ?>
<!−−< t r >
65
</ t r >
<td ></td>
67
<td ></td>
<t d nowrap= ” nowrap ” a l i g n = ” r i g h t ”>−−>
69
</ td ></ t r >
</ t a b l e >
71
<d i v a l i g n = ” r i g h t ”>
” o n c l i c k = ” l o c a t i o n . h r e f = ’ ?m= c l o s u r e&amp ; a=
a d d e d i t&amp ; p r o j e c t n a m e=<?php echo $project name ; ? > ’ ; ” />
73
</ d i v >
101
setup.php
1
<?php
if
3
directly ’ ) ;
}
5
$config = array (
’ mod name ’ => ’ Closure ’ ,
7
’ mod version ’ => ’ 1 . 0 . 1 ’ ,
’ m o d d i r e c t o r y ’ => ’ c l o s u r e ’ ,
9
’ m o d s e t u p c l a s s ’ => ’ SClosure ’ ,
’ mod type ’ => ’ user ’ ,
11
’ mod ui name ’ => ’ Closure ’ ,
’ m o d u i i c o n ’ => ’ helpdesk . png ’ ,
13
’ m o d d e s c r i p t i o n ’ => ’ ’ ,
’ p e r m i s s i o n s i t e m t a b l e ’ => ’ p o s t m o r t e m a n a l y s i s ’ ,
15
’ p e r m i s s i o n s i t e m f i e l d ’ => ’ pma id ’ ,
’ p e r m i s s i o n s i t e m l a b e l ’ => ’ p r o j e c t n a m e ’
17
);
19
i f (@$a == ’ setup ’ ) {
echo dPshowModuleConfig ( $ c o n f i g ) ;
21
}
23
c l a s s SClosure {
25
function i n s t a l l () {
$ok = t r u e ;
27
$q = new DBQuery ;
$sql = ” (
29
pma id i n t e g e r n o t n u l l a u t o i n c r e m e n t ,
project name varchar (255) not n u l l d e f a u l t
31
’’,
p r o j e c t s t a r t d a t e datetime d e f a u l t n u l l ,
project end date datetime d e f a u l t n u l l ,
33
p r o j e c t p l a n n e d s t a r t d a t e datetime d e f a u l t n u l l ,
project planned end date datetime d e f a u l t n u l l ,
35
project meeting date datetime d e f a u l t n u l l ,
planned budget t e x t ,
37
budget t e x t ,
participants text ,
39
project strength text ,
project weaknesses text ,
41
improvement suggestions t e x t ,
conclusions text ,
102
p r i m a r y key ( pma id )
43
)”;
45
$q−>c r e a t e T a b l e ( ’ p o s t m o r t e m a n a l y s i s ’ ) ;
$q−>c r e a t e D e f i n i t i o n ( $ s q l ) ;
47
$ok = $ok && $q−>exec ( ) ;
$q−>c l e a r ( ) ;
49
if
51
( ! $ok )
return false ;
return null ;
53
}
55
f u n c t i o n remove ( ) {
$q = new DBQuery ;
57
$q−>dropTable ( ’ p o s t m o r t e m a n a l y s i s ’ ) ;
$q−>exec ( ) ;
59
$q−>c l e a r ( ) ;
61
return null ;
63
}
65
f u n c t i o n upgrade ( $ o l d v e r s i o n ) {
return true ;
}
67
}
69
?>
103
view.php
1
<?php
if
3
directly ’ ) ;
}
5
$config = array (
’ mod name ’ => ’ Closure ’ ,
7
’ mod version ’ => ’ 1 . 0 . 1 ’ ,
’ m o d d i r e c t o r y ’ => ’ c l o s u r e ’ ,
9
’ m o d s e t u p c l a s s ’ => ’ SClosure ’ ,
’ mod type ’ => ’ user ’ ,
11
’ mod ui name ’ => ’ Closure ’ ,
’ m o d u i i c o n ’ => ’ helpdesk . png ’ ,
13
’ m o d d e s c r i p t i o n ’ => ’ ’ ,
’ p e r m i s s i o n s i t e m t a b l e ’ => ’ p o s t m o r t e m a n a l y s i s ’ ,
15
’ p e r m i s s i o n s i t e m f i e l d ’ => ’ pma id ’ ,
’ p e r m i s s i o n s i t e m l a b e l ’ => ’ p r o j e c t n a m e ’
17
);
19
i f (@$a == ’ setup ’ ) {
echo dPshowModuleConfig ( $ c o n f i g ) ;
21
}
23
c l a s s SClosure {
25
function i n s t a l l () {
$ok = t r u e ;
27
$q = new DBQuery ;
$sql = ” (
29
pma id i n t e g e r n o t n u l l a u t o i n c r e m e n t ,
project name varchar (255) not n u l l d e f a u l t
31
’’,
p r o j e c t s t a r t d a t e datetime d e f a u l t n u l l ,
project end date datetime d e f a u l t n u l l ,
33
p r o j e c t p l a n n e d s t a r t d a t e datetime d e f a u l t n u l l ,
project planned end date datetime d e f a u l t n u l l ,
35
project meeting date datetime d e f a u l t n u l l ,
planned budget t e x t ,
37
budget t e x t ,
participants text ,
39
project strength text ,
project weaknesses text ,
41
improvement suggestions t e x t ,
conclusions text ,
104
p r i m a r y key ( pma id )
43
)”;
45
$q−>c r e a t e T a b l e ( ’ p o s t m o r t e m a n a l y s i s ’ ) ;
$q−>c r e a t e D e f i n i t i o n ( $ s q l ) ;
47
$ok = $ok && $q−>exec ( ) ;
$q−>c l e a r ( ) ;
49
if
51
( ! $ok )
return false ;
return null ;
53
}
55
f u n c t i o n remove ( ) {
$q = new DBQuery ;
57
$q−>dropTable ( ’ p o s t m o r t e m a n a l y s i s ’ ) ;
$q−>exec ( ) ;
59
$q−>c l e a r ( ) ;
61
return null ;
63
}
65
f u n c t i o n upgrade ( $ o l d v e r s i o n ) {
return true ;
}
67
}
69
?>
105
APÊNDICE B -- Formulário de avaliação
Questionário de avaliação - Encerramento de
projetos
Este questionário é parte do nosso trabalho de desenvolvimento de um módulo para o
encerramento de projetos, para a ferramenta de gerenciamento de projetos dotProject. O trabalho
vem sendo realizado pela graduanda Suzana Pescador, sob a orientação da Prof. rer. nat.
Christiane Gresse von Wangenheim, PMP do GQS – Grupo de Qualidade de Software do INCoD Instituto Nacional para Convergência Digital (http:// www.incod.ufsc.br).
Nós gostaríamos de saber a sua opinião sobre a utilidade e usabilidade do módulo (acessível em:
http://wwwexe.inf.ufsc.br/~suzana/dotproject/). A implementação atual representa um primeiro
protótipo do módulo, que implementa as funções básicas deste processo. Nós gostaríamos de
convidá-lo a registrar, editar, visualizar e deletar uma ata de pós-morte. Isto não deve tomar mais
do que 15 minutos do seu tempo. Sua participação é totalmente voluntária. As informações obtidas
deste questionário serão tratadas de forma acumulativa, não permitindo a identificação de
respostas individuais. Os resultados serão utilizados para melhorar o módulo atual assim como para
futuros trabalhos.
O roteiro de execução desta atividade pode ser acessado em
http://www.inf.ufsc.br/~suzana/roteiro_atividade_dotProject.html
Se você tem algum questionamento, por favor, entre em contato conosco: Suzana Pescador
([email protected]).
Agradecemos a participação no nosso trabalho,
Suzana Pescador e Prof. rer. nat. Christiane Gresse von Wangenheim
* Required
Eu considero o módulo útil para encerrar os projetos da empresa *
1
2
3
4
5
Discordo totalmente
Concordo totalmente
Eu considero o módulo útil para documentar as reuniões de pós-morte do projeto *
1
2
3
4
5
Discordo totalmente
Concordo totalmente
Eu considero o módulo útil para gerenciar lições aprendidas durante os projetos *
1
2
3
4
5
Discordo totalmente
Concordo totalmente
Eu considero o módulo útil para identificar pontos fortes e fracos da empresa, através das
lições aprendidas *
1
Discordo totalmente
2
3
4
5
Concordo totalmente
Eu considero o módulo de fácil manipulação e conteúdo intuitivo *
Em termos de usabilidade
1
2
3
4
5
Discordo totalmente
Concordo totalmente
Quais foram os principais pontos fortes que você observou? *
Quais foram as principais melhorias que você sugere? *
Outros comentários
Submit
Powered by Google Docs
Report Abuse - Terms of Service - Additional Terms
108
APÊNDICE C -- Roteiro de simulação de uso
do novo módulo
Roteiro de avaliação do módulo de encerramento
A execução deste roteiro faz parte da avaliação da implementação do módulo de
encerramento de projetos na ferramenta dotProject.
Para a realização das atividades, foi criado um projeto exemplo, chamado Pizzaria
OnLine. Este projeto consiste em criar um aplicativo para smartphones, através do qual
entregadores de pizza possam consultar endereços, pedidos, preços, entre outros. Além
disso, o escopo do projeto inclui o desenvolvimento de uma página web onde poderão ser
feitos os pedidos on-line das pizzas, consulta de cardápio e contato com os vendedores.
A atividade pressupõe que o projeto acabou. Foi realizada uma reunião de pós-morte, com
a participação da programadora Peach, o gerente Toad, o entregador de Pizza Yoshi e o
atendente da pizzaria, Luigi. Na reunião foram levantados os seguintes tópicos:
Pontos fortes:
A linguagem de programação Cobra ofereceu abstrações que facilitaram o
desenvolvimento do software dos smartphones
O escopo foi facilmente alterado e gerenciado, uma vez que os clientes estavam
próximos ao desenvolvimento e presentes em todas as reuniões marcadas
O desenvolvimento da página web foi mais rápido que o previsto, uma vez que a
tecnologia escolhida já era de pleno conhecimento dos programadores
Pontos fracos:
O fornecedor X dos smartphones atrasou a entrega dos produtos em 30 dias
Foi necessário um treinamento dos programadores nas tecnologias móveis
Os usuários finais do software (entregadores de pizza e atendente da pizzaria)
tiveram dificuldade na instalação dos módulos
Além disso, notou-se que:
O cronograma atrasou em 35 dias
O orçamento superou o previsto em 10%
Com base nestas informações, pedem-se três tarefas:
Primeiramente, logue no sistema com as credenciais:
login: admin
senha: passwd
1. Tarefa: Registro e edição da ata
1. Navegue até o projeto 'Pizzaria OnLine'
2. Vá até a ata 'Post Mortem Analysis'
3. Clique em 'new post mortem'
4. Registre a ata da reunião acima descrita*
5. Clique em 'submit'
6.
Ao clicar no ícone, abre-se a página de edicão do projeto
7. Edite os campos desejados (adicione o contato 'Suzana' ao participantes, e
altere o orçamento final, por exemplo).
8. Verifique, no canto superior esquerdo, que é possível visualizar esta ata deste
ponto
9. Clique em 'submit' e veja as alterações
2. Tarefa: Visualizar uma ata
1. Repita os passos 1.1 e 1.2
2. Clique na data da reunião da ata que deseja visualizar
3. Verifique, no canto superior esquerdo, que é possível editar esta ata deste
ponto
3. Tarefa: Visualizar a base de experiências da empresa
1. Navegue até a empresa 'Toad Software' e clique na aba 'Experience Factory'
2. Verifique que a aba apresenta a listagem de todas as atas dos projetos da
empresa
* O calendário do dotProject possui um bug para algumas datas, portanto, é bom verificar com cuidado
as datas escolhidas no calendário e as datas adicionadas no campo
Terminada a atividade, você poderá então responder ao questionário.
Agradecemos a participação em nosso trabalho,
Suzana Pescador e Prof. rer. nat. Christiane Gresse von Wangenheim

Evolução da Ferramenta dotProject para Suporte ao Encerramento

Transcrição

Documentos relacionados

4) Digite o trecho de programa abaixo e salve

Chat Box em PHP - Comunidade Portuguesa de PHP

Untitled

Gabriel Silva Gandolfo

new App. 2013 GEL MM

Declaração de Entrada

Duvida ajuda pff Re:Duvida ajuda pff

Softwares e versões

I authorize PASB to add to the next month`s tuition bill the amount

Problema de date() - Comunidade Portuguesa de PHP