manuel ribeiro sebastiao - contabilidade e finanças metodista/intro fin... · actividades do...
TRANSCRIPT
11
Manuel Ribeiro Sebastiao
Gestão de Projectos: Implementação de 1 ERP
Trabalho apresentado ao curso MBA em
Gestão de Projectos, Pós-Graduação lato
sensu, realizado na Brazilian Business
School _ Escola Internacional de Negócios
como requisito parcial para a obtenção do
Grau de Especialista em Gerência de
Projectos.
ORIENTADOR: Prof. Tânia Belmiro
Luanda
Março/ 2012
12
BRAZILIAN BUSINESS SCHOOL
ESCOLA INTERNACIONAL DE NEGÓCIOS
MBA EM GERÊNCIA DE PROJECTOS
O Trabalho de Final de Curso
Desenvolvimento de 1 ERP
Elaborado por: Manuel Ribeiro Sebastiao
e aprovado pela Coordenação Acadêmica do curso de MBA em Gestão de
Projectos, foi aceite como requisito parcial para a obtenção do certificado do curso
de pós-graduação, nível de especialização da Brazilian Business School _ Escola
Internacional de Negócios .
Local, Data
Tânia Regina Belmiro
Coordenadora Acadêmica
Nome do Prof. Orientador
13
14
DECLARAÇÃO
A empresa EPOLOMBO Lda, representada neste documento pelo Sr.(a) Jose
Camorteiro, Director Geral autoriza a divulgação das informações e dados coletados
em sua organização, na elaboração do Trabalho de Final de Curso intitulado
Desenvolvimento de 1 ERP, realizado pelo aluno Manuel Ribeiro Sebastiao, do
curso de MBA em Gerência de Projectos da Brazilian Business School _ Escola
Internacional de Negócios, com o objetivo de publicação e/ ou divulgação em
veículos acadêmicos.
Luanda, 2012-03-01
Director Geral
Epolombo Lda
15
TERMO DE COMPROMISSO
O aluno Manuel Ribeiro Sebastiao, abaixo assinado, do curso de MBA em
Gerência de Projectos, Turma Gestão de Projecto 2011 da Brazilian Business
School _ Escola Internacional de Negócios, no período de dd/mm/aa a dd/mm/aa,
declara que o conteúdo do Trabalho de Final de Curso intitulado Desenvolvimento
de 1 ERP,é autêntico, original e de sua autoria exclusiva.
________________________________________
Manuel Ribeiro Sebastiao
16
Dedicatória
Dedico esta magna obra as Sras: Isabel Ribeiro Sebastiao, e Georgina da
Conceicao Miguel Sebastiao Ribeiro. Dizer que são as mulheres mais lindas e mais
belas deste universo.
Amo Muito Voces
17
Resumo
O presente trabalho consiste na elaboração de um Plano de Projectos para a
implantação de 1 Software de Gestão (ERP) para uma empresa de venda de
Refrigerantes e Produtos alimentícios. Para tal, foram implementadas todas as
técnicas e conhecimentos aprendidos durante o MBA de Gestão de Projectos.
A empresa em questão e a nossa equipa de Projectos reuniram para fazer a análise
de viabilidade do projecto, definindo assim as metas e objectivos do mesmo,
concluíndo que ficaria mais em conta a elaboração de 1 Software de raiz, que
satisfizesse as necessidades do cliente e que garantisse experiência à nossa
equipa.
Houve a necessidade de reunir uma equipa de projectos constituída por 1 Gestor de
Projectos capacitado, para garantir que todas as etapas do projecto fossem
concluídas, uma equipa de Desenvolvimento de Software, onde se enquadram
programadores, analistas de sistema e administradores de Base de Dados,
Financeiros, para melhor controle dos custos,área de Logística, para aquisição de
material (compras) e 1 advogado para garantir a transparência no contracto.
O projecto foi desenvolvido em várias fases, obedecendo as 9 áres de conhecimento
estudadas, começando pelo Termo de abertura resultante da reunião das equipas.
Seguiu-se a Declaração de Escopo, elaborada a partir do termo de abertura,
evidenciando o que o projecto deve fazer, bem como aquilo que não deve fazer. As
actividades do projecto foram colocadas na WBS sob a forma de um fluxograma de
fácil leitura. São ainda abordados os Planos para a Gestão de Custos, onde são
descritos todos os gastos do Projecto, o Plano de Gestão de Tempo, onde são
listadas de forma sequencial as actividades do Projecto, especificando o número de
dias que cada actividade deve ter de forma a calcular o tempo total do projecto e as
suas folgas, o Plano de Gestão de Riscos, para identificar todos os riscos do
projecto, de forma a evitar ou minimizar o impacto desses riscos sobre o projecto, o
Plano de Gestão de Recursos Humanos, para gestão do pessoal, o Plano de Gestão
de Qualidade, para garantir os padrões aceitáveis, o Plano de Gestão de Aquisições,
18
o Plano de Gestão de Integração dos diferentes planos e o Plano de Comunicação,
para garantir que todas as partes envolvidas no Projecto estejam a par do
andamento do mesmo bem como de todas as mudanças.
O Projecto foi desenvolvido num prazo de 3 meses (90 dias) e o orçamento foi de
100000USD.
Palavras Chave: empresa EPOLOMBO,Software, ERP, venda de
Refrigerantes e Produtos alimentícios, Cachilimbichimue Soft, Gestão de Projecto,
áreas de conhecimento, processos, projecto
19
Abstract
The company EPOLOMBO Ltd is a company that sells soft drinks and food products.
In recent months his business has increased exponentially, increasing not only sales
volume but also the geographic areas, spreading in all provinces of the country.
Unfortunately this company does not have any software to manage its business, not
having tools to manage its business and get sales reports, the likelihood of fraud and
loss is too great. Not having enough money, they preferred to contact our software
development company (Cachilimbichimue Soft) to develop a software that adapts to
their business.
Given this growth and the need to better manage their business, the company
EPOLOMBO Ltd, represented by its Manager Director, José António, decided to
meet with the Board of the Company Cachilimbichimue Soft to develop an ERP-
Software, encompassing only the following modules: Inventory, Customers,
Suppliers, Accounting, Sales and Purchasing. After signing the contract, the
application should be developed within approximately 3 months (90 days) and the
budget is about 100000USD.
It is proposed in this paper to elaborate the document on the management of this
project addressing in detail each of the nine knowledge areas within the five
processes, describing the steps taken to prepare the project.
Key Words: EPOLOMBO Company,Software, ERP, sell soft drinks and food
products, Cachilimbichimue Soft, Project Management, knowledge areas, Processes,
Project
20
AGRADECIMENTOS
Os meus sinceros agradecimentos vão inicialmente ao supremo Deus todo poderoso pela protecção ao longo deste tempo, pela sabedoria que me tem dado, pelo conhecimento e pela vida acima de tudo. Quero agradece-Lo no nome do nosso Sr, Jesus Cristo, Ele que estado comigo e com minha familia todos os dias da minha vida. Agradecimento a minha tutora Dra Tania por ter sido ao longo deste periodo uma conselheira, uma amiga, uma mae, alguem que sempre esteve disposto em nos ajudar, nela vai o nosso muito aobrigado; Ao pessoal da BBS de angola e no brasil, as professores que na sua maioria foram brasileiros, vai o nossa mais sincero agradecimento pelo facto de muitas vezes terem que deixar seu pais assim como seus familiares a afazeres para dispensarem aqui em angola o vosso saber, tambem o nosso muito obrigado. A minha esposa, que sempre esteve acordada esperando por mim na calada da noite preocupada com meus estudos, aos meus filhos, meus cassules yanick bentinho sany e belinha, a minha mama, aos meus alunos e a todos que de forma directa ou indirecta contribuiram para este grande momento da minha vida
A LUTA FOI DURA MAS VENCEMOS,
PAI se em caso algum pequei contra Ti ao longo desta minha formação, peço o
seu perdão e receba este trabalho porque sei que sem a Tua presença nada
do que aqui esta seria possível.
Obrigado Nosso Senhor. Jesus Cristo.
21
“Quanto mais você conhece seu
projecto, mais será capaz de o
gerir”
Guia PMBOK
22
SUMÁRIO
BRAZILIAN BUSINESS SCHOOL _ ESCOLA INTERNACIONAL DE NEGÓCIOS ........................... 12
MBA EM GERÊNCIA DE PROJECTOS ................................................................................. 12
DEDICATÓRIA ...................................................................................................................... 16
RESUMO ................................................................................................................................. 17
ABSTRACT ............................................................................................................................ 19
AGRADECIMENTOS ............................................................................................................ 20
1. INTRODUÇÃO ........................................................................................................................ 26
1.1.CONSIDERAÇÕES INICIAIS .................................................................................................. 26
1.2. HISTÓRIA E EVOLUÇÃO ...................................................................................................... 29
1.3 FORMAÇÃO DE INSTITUIÇÕES DE GESTÃO DE PROJECTOS .............................................. 31
2.FUNDAMENTAÇÃO TEÓRICA ....................................................................................... 32
2.1. CONSIDERAÇÕES INICIAIS ................................................................................................. 32
2.2 O QUE É 1 PROJECTO? ..................................................................................................... 32
2.3 GESTÃO DE PROJECTOS .................................................................................................... 33
2.4 STAKEHOLDERS ................................................................................................................. 41
2.5 GESTOR DE PROJECTO ...................................................................................................... 41
3. METODOLOGIA CIENTÍFICA ................................................................................................... 43
3.1. CONSIDERAÇÕES INICIAIS ................................................................................................. 43
3.2. VISITAS .............................................................................................................................. 43
3.2.1 Reunião 1 ...................................................................................................................... 43
3.2.2 Reunião 2 ...................................................................................................................... 43
3.2.3 Reunião 3 ...................................................................................................................... 44
3.2.4 Reunião 4 ...................................................................................................................... 44
3.2.5 Reunião 5 ...................................................................................................................... 44
3.2.6 Reunião 6 ...................................................................................................................... 45
23
3.2.7 Reunião 7 ...................................................................................................................... 45
3.2.8 Reunião 8 ...................................................................................................................... 45
3.3 QUESTIONÁRIOS ................................................................................................................. 45
3.3.1 Questionário de Clientes ............................................................................................ 46
3.3.2 Questionário de Inventário ......................................................................................... 46
3.3.3 Questionário de Compras ........................................................................................... 46
3.3.4 Questionário de Fornecedores .................................................................................. 46
3.3.5 Questionário de Vendas ............................................................................................. 46
4. PLANO DE PROJECTO .......................................................................................................... 47
4.1. CONSIDERAÇÕES INICIAIS ................................................................................................. 47
4.2. PLANO DE GESTÃO DE ESCOPO ...................................................................................... 47
4.2.1 Termo de Abertura ....................................................................................................... 48
4.2.2 Declaração de Escopo ................................................................................................ 51
4.2.3 Criar a EAP ................................................................................................................... 54
4.2.4 Verificar o Escopo ........................................................................................................ 54
4.2.5 Controlar o Escopo ...................................................................................................... 55
4.3 PLANO DE GESTÃO DE TEMPO .......................................................................................... 56
4.3.1 Definir as actividades .................................................................................................. 57
4.3.2 Sequenciar as actividades ......................................................................................... 57
4.3.3 Estimar os Recursos das actividades ....................................................................... 57
4.3.4 Estimar as durações das actividades ....................................................................... 57
4.3.5 Diagrama de Redes ..................................................................................................... 58
5. CONCLUSÕES ........................................................................................................................ 60
6. POSSÍVEIS DESDOBRAMENTOS ............................................................................................ 81
7. REFERÊNCIAS BIBLIOGRÁFICAS ........................................................................................... 82
8. GLOSSÁRIO .......................................................................................................................... 82
AQUI VOCÊS PODEM INCLUIR DOCUMENTOS, PLANILHAS DESENHOS RELACIONADOS AO TEXTO
ACIMA. ....................................................................................................................................... 82
9.1. APÊNDICE I – .... ............................................................................................................... 82
24
LISTA DE FIGURAS E TABELAS
FIGURA 1 - DIAGRAMA DE PERT ................................................................................... 30
FIGURA 2 - DIAGRAMA CPM ............................................................................................ 30
FIGURA 3 - A CONSTANTE TRIPLA ............................................................................... 35
FIGURA 4 - A ESTRUTURA EM LOSÂNGULO ............................................................. 35
FIGURA 5 - GRUPOS DE PROCESSOS (GUIA PMBOK, 2008) ................................. 36
FIGURA 6 - PROCESSOS DE PLANEAMENTO(FONTE GUIA PMBOK, 2008) ..... 38
FIGURA 7 - PROCESSOS DE CONTROLE (GUIA PMBOK, 2008) ........................... 40
FIGURA 8 - VISÃO GERAL DA GESTÃO DO ESCOPO DO PROJECTO
SEGUNDO O GUIA PMBOK 2008 ..................................................................................... 48
FIGURA 9 - VISÃO GERAL DA GESTÃO DO TEMPO DO PROJECTO SEGUNDO
O GUIA PMBOK 2008 .......................................................................................................... 56
FIGURA 10 - DIAGRAMA DE REDES DO PROJECTO ................................................ 58
25
26
1. INTRODUÇÃO
1.1.Considerações Iniciais
No mundo globalizado em que vivemos, sujeito a rápidas mudanças e onde a
concorrência se torna cada vez maior e mais agressiva, aumenta a necessidade das
organizações possuirem uma estrutura virada para projectos, saindo da velha rotina
onde toda a acção tomada era na verdade uma reacção a qualquer problema ou
necessidade. Desta forma, a preparação de profissionais em curto espaço de tempo,
com competência, qualidade e a custos reduzidos para gerenciar com sucesso os
projectos surge como consequência das necessidades do cenário actual.
Com a estrutura virada para Projectos, as organizações tendem a antecipar os
problemas, tendo uma estrutura mais organizada, com profissionais cada vez mais
capacitados e orientados na obtenção de resultados.
Actualmente vemos a necessidade das organizações, sejam elas privadas ou
públicas, de aprimorarem seus métodos de gestão no desenvolvimento de projectos,
visando sobretudo a optimização dos recursos disponíveis – sejam eles humanos,
materiais ou financeiros. (Edgar Vale Ribeiro 2011)
Na busca desta optimização, observamos que muitas organizações têm
modificado a sistemática de gestão, procurando deixar sua estrutura mais leve e
competitiva. Entretanto, outras instituições ainda estão atreladas a uma forte
organização funcional, onde a relação de autoridade é claramente vertical: cada
funcionário tem um superior bem definido, com grande agrupamento das
especialidades em sectores especificos do trabalho. Esta sistemática
invariavelmente dificulta o desenvolvimento de projectos, que acaba por ultrapassar
os prazos e os custos estimados.
Em determinados tipos de empresas ou em órgãos públicos, incluíndo-se aí as
Organizações Militares, acontece uma situação pouco usual para empresas
privadas, que é a rotatividade elevada entre os membros da direcção, comando ou
chefia. Isto porque os cargos são preenchidos por indicações políticas ou são
27
comissionados por tempo pré-determinado. Como desenvolver então projectos neste
ambiente, onde por exemplo, de dois em dois anos uma nova pessoa assume a
direcção, trazendo toda uma bagagem de conhecimento, mas também com
interesses próprios, que nem sempre são coincidentes com o que já havia sito
traçado pelo seu antecessor?
A solução é ter uma metodologia de gestão que propicie uma visualização
perfeita do que é o projecto; que facilite a comunicação entre os envolvidos
directamente no trabalho relizado, que procure o comprometimento do grupo em
torno do objectivo final. (Edgar Vale Ribeiro, 2011).
A gestão correcta de projectos traz benefícios para a organização, podendo ser
utilizada na resolução de problemas ajudando na tomada de decisão e ainda
identificando efeitos e causas, possibilitando assim a organização a desenvolver
uma visão do futuro, estabelecendo estratégias e tendo como resultado a motivação
e inspiração da equipa, tornando os desafios maiores e posteriormente trazer “o
gosto de vitória” (Daiani Furtado, 2011) . Esses benefícios podem reflectir-se em:
Melhores resultados;
Previsibilidade;
Aumento da lucratividade;
Aumento da chance de sucesso nos projectos;
Aumento da satisfação dos clientes;
Os gestores devem ficar atentos aos factores que demonstram a necessidade de
uma boa gestão de projectos, iniciando pela análise da competitividade, verificando
se as margens de lucros estão dentro do patamar das estratégias, analisando as
exigências dos clientes, os avanços tecnológicos e outros factores que trazem a
possibilidade de implantar e gerenciar um projecto para trazer os benefícios para o
crescimento da empresa. (Daiani Furtado,2011).
O cenário de negócios actual exige das empresas maior velocidade,
flexibilidade e consistência na implementação de suas estratégias para
sobrevivência e crescimento. A execução destas estratégias envolve certas etapas
28
que competem por recursos(humanos, financeiros e materiais) com as actividades
rotineiras da organização, aumentando a complexidade da gestão empresarial.
Para viabilizar esse cenário, começam a ser desenvolvidas novas estruturas de
negócio, para fazer com que os planos estratégicos possam ser implementados por
meio de projectos. Estes planos estratégicos possuem objectivos específicos e
restrições (orçamentárias, prazo, qualidade ou recursos) que devem nortear
projectos ou programas dentro de uma organização.
E para possibilitar que essas novas estruturas se viabilizem, valoriza-se também a
figura do gestor de projectos. As empresas começam a dar preferência ao
profissional certificado, com experiência, que faz uso de melhores práticas, da
ferramentas adequadas para aumentar a efectividade de seus programas e
projectos. (Manager Brazil – www.managerbrazil.com.br)
As organizações, para colherem os benefícios esperados, devem adoptar a gestão
de projectos não somente como uma profissão, mas como uma metodologia na qual
os seus gerentes devam ser devidamente treinados, de forma a agregar valor às
experiencias individuais de cada um deles. A gestão de projectos deve ser feita de
forma profissional e conduzida por pessoal qualificado. Desta forma, a cultura de
projectos nas organizações deve ser criada, a sua implementação deve ser realizada
de forma sistemática e os seus princípios colocados em prática da maneira mais
adequada às necessidades das organizações.
Conclui-se que, gerenciar de forma adequada os projectos dentro das
organizações, traz benefícios financeiros e de crescimento em pouco tempo e
principalmente na questão de sobrevivência da organização no mercado
competitivo, trazendo um diferencial na forma de gerenciá-la. As organizações que
utilizam esta metodologia (Gestão de Projectos) conseguem optimizar os seus
recursos, tornando-se mais competitivas. Da mesma forma, organizações públicas
podem contribuir eficazmente na economia de verbas e na qualidade dos serviços
prestados à população. (Daiani Furtado, 2011)
29
1.2. História e evolução
A Gestão de Projectos é uma prática muito antiga, as civilizações antigas já
usavam de forma indirecta, como exemplo disso temos a pirâmide de Giza, o
coloseu romano, as catedrais góticas da Europa, Taj Mahal etc. Tais projectos já
possuiam tecnologia avançada, aquisição de materiais, recursos humanos e gestão
de tempo e custo. Os arquitectos e mestres desses projectos tinham total
compreensão da magnitude de seus projectos, incluindo as principais actividades a
serem desenvolvidas e sua EAP (Estrutura Analítica de Projecto) .
No entanto Henry Gantt (1861-1919) e Henri Fayol (1841-1925) são
considerados por muitos como sendo os pais da Gestão de Projectos moderna. O
primeiro, considerado pai das técnicas de planeamento e controle, famoso pelo seu
uso do gráfico de Gantt como uma ferramenta de Gestão de Projectos e o segundo
pela criação das 5 funções que formam a base do corpo de conhecimento associado
a Gestão de Projectos: Planear, Organizar,Controlar, Coordenar e Comandar. Eram
ambos estudantes das teorias de Frederick Taylor (1856-1915) da administração
científica, seu trabalho é o percursor de ferramentas modernas de gestão, incluindo
projecto de Estrutura Analítica de Projecto (EAP) e alocação de recursos.
(Wikipédia,2010)
A Gestão de Projectos no senso moderno começou no inicio dos anos 1950’s,
embora tenha as suas raízes no final do século XIX. Foi desenvolvida a partir de
diversos campos, incluindo a construção, telecomunicações, engenharia e defesa
militar. A necessidade de Gestão de Projectos foi conduzida por negócios que deram
conta dos benefícios de evitar repetição de trabalho e a necessidade crítica de
comunicar e coordenar o trabalho entre departamentos e professionais. Um dos
principais usos da gestão de projectos como nós conhecemos hoje foi para gerir o
espaço áereo dos Estados Unidos. O Governo, militares e o mundo corporativo
adoptaram agora esta prática. (Wikipédia,2010) Foram então desenvolvidas duas
técnicas de Gestão de projectos:
1. PERT: Desenvolvido como parte do programa do míssil do submarino
Polaris da marinha dos Estados Unidos em 1957. É utilizado em Gestão
30
de Projectos para analisar e representar tarefas de 1 projecto,
especialmente o tempo necessário para completar cada tarefa e para
identificar o tempo mínimo necessário para completar todo o projecto.
Consiste no cálculo a partir da média ponderada de 3 durações
possíveis de uma actividade (optimista, mais provável e pessimista).É
utilizado em projectos onde a gestão de tempo é mais importante que a
gestão de custos.
Figura 1 - Diagrama de PERT
2. CPM: Desenvolvido em conjunto por DuPont Corporation e Remington
Rand Corporation entre 1940 e 1943. É um método de apuração do
caminho crítico dada uma sequência de actividades, isto é, quais
actividades de uma sequência não podem sofrer alteração de duração
sem que isso reflita na duração total de um projecto.
Figura 2 - Diagrama CPM
31
1.3 Formação de Instituições de Gestão de Projectos
As duas maiores instituições de Gestão de Projectos foram criadas nos anos
60, uma na Europa e outra nos Estados Unidos. A criação destas instituições foi
fruto da evolução da Gestão de Projectos, que começou a ganhar outra dimensão
nessa altura. (PM World Today, 2007)
A Internacional Project Management Associtaion (IPMA) foi fundada na Europa
em 1965, como uma federação de várias associações nacionais de gestão de
projecto. Sendo que o seu primeiro congresso mundial foi em 1967. Inicialmente o
seu nome era IMSA e só mais tarde mudou para IPMA.
Em 1969, o Project Management Institute (PMI) foi formado nos Estados
Unidos. Seu primeiro seminário realizou-se em Atlanta (Estados Unidos). Na década
de 70 realizou-se o primeiro capítulo. Na década de 80 realizou-se a primeira
avaliação para a certificação como profissional em gestão de Projectos – PMP. Na
década de 90 o PMI publica “A Guide to Project Management Body of Knowledge”
(Guia PMBOK,2008), que descreve as práticas de gestão de projectos que são
comuns a maioria dos projectos e servem de pilar básico para a gestão e Direcção
de Projectos. O PMI é hoje a maior instituição mundial de Gestão de projectos, com
mais de 300000 associados em mais de 160 países.
32
2.FUNDAMENTAÇÃO TEÓRICA
2.1. Considerações Iniciais
O objectivo deste capítulo é apresentar o referencial teórico referente à Gestão
de Projectos, apresentando os principais pensamentos dos autores que tratam do
tema em questão.
2.2 O que é 1 Projecto?
Antes de se abordar o tema Gestão de Projectos é importante ter-se uma
noção do que é um Projecto. “Projecto é o esforço temporário empreendido para
criar 1 produto,serviço ou resultado exclusivo. A sua natureza temporária indica um
início e um término definidos. O término é alcançado quando os objectivos tiverem
sido atingidos e o projecto for encerrado, ou quando o mesmo não for mais
necessário. Temporário não significa necessariamente de curta duração. Além disso,
geralmente o termo temporário não se aplica ao produto, serviço ou resultado criado
pelo projecto; a maioria dos projectos é realizado para criar 1 resultado duradouro.
Os projectos também podem ter impactos sociais, econômicos e ambientais com a
duração mais longa do que a do próprio projecto. Cada projecto cria um produto,
serviço ou resultado exclusivo. Embora elementos repetitivos possam estar
presentes em algumas entregas do projecto, essa repetição não muda a
singularidade fundamental do trabalho do projecto. Por exemplo, prédios de
escritórios são construídos com os materiais idênticos ou similares ou pela mesma
equipa, mas cada um é exclusivo – com diferentes projectos, circunstâncias,
fornecedores etc”. (Guia PMBOK, 2008)
Quando se fala de projectos pensa-se logo em algo de grande magnitude, isso
é um erro, pois um projecto pode estar envolvido com pequenas actividades do dia-
a-dia. É possível citar-se alguns exemplos na resolução de problemas internos,
negociação com fornecedores, entrega de produtos, implementação de sistemas
informáticos etc. (Daiani Furtado, 2011)
33
2.3 Gestão de Projectos
Vários autores abordam a Gestão de Projectos com ligeiras variações de
conceito:
Segundo Turner(1994), “a Gestão de Projectos é um processo através do qual
um projecto é levado a uma conclusão. Tem três dimensões:
Objectivos (âmbito, organização, qualidade,custo, tempo);
Processo de Gestão (Planear, organizar,implementar,controlar);
Níveis(Integrativo, estratégico, tático)”
De facto, tal como foi dito no ponto anterior, todo o projecto tem uma conclusão,
tornando-o temporário. A conclusão do mesmo dá-se quando os objectivos do
Projecto foram alcançados ou quando é impossível alcançar os mesmos. Todo o
Projecto tem um objectivo, esse objectivo pode passar pelo melhoramento da
qualidade de um produto ou serviço, organização da empresa, criação de um novo
Produto etc.
Já o PMI (2004) define Gestão de Projectos “como sendo o processo através do qual
se aplicam conhecimentos, capacidades, instrumentos e técnicas às actividades do
projecto de forma a satisfazer as necessidades e expectativas dos diversos
Stakeholders, que são indivíduos activamente envolvidos no Projecto ou cujo o
resultado do mesmo poderá afectá-los de forma positiva ou negativa”. Com esta
definição torna-se claro que o objectivo da Gestão de Projectos é o de satisfazer as
exigências das partes envolvidas no Projecto. Para tal todas as actividades afectas
ao mesmo devem ser geridas pondo em prática todo o conhecimento obtido através
da correcta Gestão de Projectos, aplicando os instrumentos e técnicas de forma a
reduzir o custo, tempo e aumentando a qualidade, diminuindo assim a probabilidade
de fracasso.
Reduzida à sua forma mais simples e confinada a uma das suas nove áreas de
conhecimento (de acordo com o Guia PMBOK,2008), a Gestão de Projectos pode
ser definida “como sendo a disciplina de manter os riscos de fracasso a um nível
baixo durante o ciclo de vida do projecto, potenciando ao mesmo tempo, as
oportunidades de ocorrência de eventos favoráveis ao Projecto. O risco de fracasso,
decorrente da ocorrência de ameaças, aumenta de acordo com a presença de
34
incerteza do evento e da sua probabilidade de ocorrência, durante todos os estágios
do Projecto” (Wikipédia,2010). A gestão de riscos desempenha um papel
fundamental para a Gestão de Projectos, sendo talvez a área mais importante
quando se fala em Planeamento, Controlo/Monitoramento e Execução. Com a
correcta gestão dos riscos, podem ser identificados todos os possiveis problemas
internos ou externos que afectem de forma directa ou indirecta o Projecto, criando
planos de acção caso esses riscos ocorram, desta formar pode-se garantir também
que seja alocado um certo custo e tempo para resolução desses riscos, bem como
recursos (humanos e materiais) sem que o Produto/Serviço final sofra mudança,
uma vez que o risco foi identificado, as medidas/acções foram descritas e os custos
e prazos das actividades foram previstos.
Um ponto de vista alternativo diz que Gestão de Projectos “é a disciplina de definir e
alcançar objectivos ao mesmo tempo em que se optimiza o uso de recursos
(tempo,dinheiro,pessoas, espaço etc)” (Wikipédia,2010). Apesar de curta, esta
definição engloba grande parte do conceito de Gestão de Projectos, porém está
incompleta, pois não engloba aspectos relacionados com comunicação e qualidade,
que são dois aspectos importantes que devem ser controlados e postos em prática
pelo Gestor de Projectos. A qualidade de um projecto depende de muitos factores e
da percepção dos diferentes Stakeholders, daí a importância em se colocar todos os
aspectos bem definidos e comunicar a todos os interessados os objectivos do
projecto e das diferentes actividades bem como todas as alterações efectuadas ao
escopo do Projecto.
Já Duncan Haughey (2010) “sumariza a Gestão de Projectos num triângulo (Figura
3). Os três factores mais importantes são o Tempo, Custo e Escopo, normalmente
chamada de constante tripla. Os mesmos formam o vértice do triângulo, tendo a
qualidade como tema central.
35
Figura 3 - A constante tripla
Mais recentemente, este triângulo foi substituído por uma losângulo, com Custo,
Tempo,Escopo e Qualidade como vértices e as espectativas do cliente como sendo
o tema central (Figura 4)”
Figura 4 - A estrutura em Losângulo
Esta afirmação está correcta se for observada a partir do ponto de vista do Cliente
Final, uma vez que para o mesmo o que será visivel é o Custo, Tempo, Qualidade e
Escopo, pois são itens mensuráveis, uma vez que o custo será o valor que o cliente
irá pagar pelo produto/serviço, o tempo está relacionado com o prazo que o Gestor
de Projectos der ao Cliente, o Escopo será definido entre as duas partes e deverá
ser revisto periodicamente ou sempre que houver a necessidade de mudança do
mesmo. Já a qualidade poderá ser observada quando o projecto estiver terminado
ou durante a execução do mesmo, caso haja demonstrações de evolução do
Projecto. Todas as outras áreas podem ou não ser do conhecimento do Cliente,
como é o caso dos Riscos, que podem ou não ser comunicados ao Cliente,
36
dependeno da magnitude e objectivo do Projecto. A Comunicação também pode ser
incluída na figura acima, é importante comunicar o desenvolvimento do Projecto a
todos os Stakeholders.
A Gestão de projectos é realizada através da aplicação e integração apropriadas dos
42 processos agrupados logicamente abrangendo os 5 grupos que são:
Inicio;
Planeamento;
Execução;
Monitoramento e Controlo;
Encerramento;
Figura 5 - Grupos de Processos (Guia PMBOK, 2008)
Inicio
Nesta fase, o Gestor de Projectos define o Projecto, os seus Objectivos e metas,
Stakeholders e espectativas. Esta fase também inclui a lista de entregas do projecto,
ou seja, os resultados esperados de cada fase do Projecto. Nesta fase o Gestor de
Projectos reune com os principais Stakeholders.
37
Planeamento
O principal objectivo desta fase é a Definição das actividades do Projecto. O Gestor
de Projectos deverá definir bem o Escopo do Projecto, indicando o que o mesmo
deve fazer e o que não deve fazer, a partir daí listar todas as actividades ou tarefas,
definir como elas se relacionam entre si, quanto tempo cada actividade deverá ter
bem como os deadlines (flexiveis ou não). Deverá também definir os requisitos do
Projecto, quantas pessoas serão necessárias, custo Inicial do Projecto (pode sofrer
alterações ao longo da sua evolução), bem como todos os outros requisitos do
Projecto. É um dos processos mais complexos e como tal, um dos que ocupa mais
tempo. O Planeamento não é feito uma vez apenas, sempre que achar necessário, o
Gestor de Projectos deverá re-planear, comunicando sempre as mudanças a todos
os Stakeholders. Na figura 6 podemos ver os principais Processos dentro do
Planeamento, como se pode observar existem vários processos, desde a Definição e
planeamento do Escopo, que especifica as limitações do projecto, ou seja, o que o
mesmo deve ou não fazer, a definição das actividades e recursos, sequenciamento
das actividades, ou seja, definir precedencias entre as actividades. Estimar a
Duração de cada actividade para se poder então desenvolver o calendário das
actividades, especificando precedências e duração.
38
Figura 6 - Processos de Planeamento(Fonte Guia PMBOK, 2008)
Execução
Nesta fase o Gestor de Projectos já deve ter noção dos recursos e custos
necessários para o Projecto. Deverá então alocar os recursos e custos às
39
actividades do Projecto. Começa assim o trabalho do Projecto. Começando pela
execução do Plano de Projecto, realizando todas as actividades nele presente. É
também realizada a verificação do escopo, para garantir que se faça apenas o que
foi definido. O Controlo da qualidade também é verificado durante a execução do
Projecto, deve ser feito regularmente para garantir a qualidade do mesmo. O
desenvolvimento da equipa, desenvolvendo as habilidades individuais e colectivas
do grupo também é realizado nesta fase. Outros processos como obtenção de
Propostas, Proformas, escolha de fornecedores e seus contractos são também
incluídos nesta fase.
Monitoramento e controle
A performance do Projecto deve ser medida regularmente para se identificar as
variações daquilo que foi planeado. As variações são verificadas durante os
processos de controlo nas várias áreas de conhecimento. Conforme as variações
forem observadas, ajustamentos ao plano de projectos serão feitas repetindo os
processos de planeamento do Projecto (vistos anteriormente) quantas vezes for
necessário. Por exemplo, se houver atraso no término de uma determinada
actividade, pode requerer ajustamentos no planeamento do pessoal e mudanças no
orçamento e calendarização, pois quando uma actividade está atrasada, pode
requerer por parte do Gestor de Projectos mais trabalho nessa actividade, o que
envolve mais pessoas e outros recursos que podem aumentar o orçamento, tudo isto
com o objectivo de acelerar a actividade. Controlar também inclui tomar acções de
precaução para evitar possiveis problemas. Para toda e qualquer mudança, deve
existir um documento para controlo das mudanças, o mesmo deve conter as
assinaturas dos principais Stakeholders para garantir que os mesmos estão a par
das alterações e que aprovam as mesmas. Na figura 7 pode-se observar
detalhadamente os processos de controlo que abrangem o Escopo do Projecto,
Calendarização das actividades, Controlo de Custo, Controlo de Qualidade e
Controlo de resposta aos Riscos.
40
Figura 7 - Processos de Controle (Guia PMBOK, 2008)
Encerramento
Nesta fase, são reunidos todos os Stakeholders (Gestos de Projectos e sua equipa,
patrocinadores etc) para analisar-se o resultado final do Projecto. Nesta fase dá-se
também o encerramento de contracto com o pessoal, fornecedores, as lições
aprendidas. Resumindo, nesta fase o Projecto é dado como finalizado.
41
2.4 Stakeholders
Stakeholders são indivíduos ou Organizações que estão directamente envolvidos no
projecto, ou cujo interesse pode positivamente ou negativamente ser afectado pela
excecução ou conclusão do Projecto. É obrigação da Equipa de Projectos identificar
os Stakeholders, determinar as suas necessidades e espectativas, para então gerir
essas espectativas e assegurar o sucesso do Projecto. Quando os objectivos do
projecto são bem definidos e o escopo correctamente declarado torna-se mais fácil a
identificação dos Stakeholders. Os principais Stakeholders do Projecto podem ser:
Gestor de Projectos;
Cliente: O Indivíduo ou organização que irá usar o produto/Serviço resultante
do Projecto;
Equipa de Projectos: Equipa que trabalha com o Gestor de Projectos com o
intuito de levar o Projecto ao seu término.
Sponsor: O indivíduo ou grupo que providencia os recursos financeiros para a
realização do Projecto.
Para além destes Stakeholders existem muitos outros, gerir as espectativas dos
Stakeholders pode tornar-se difícil pois os Stakeholders possuem objectivos
diferentes, podendo haver conflito de interesses. Gerir esses conflitos é uma das
principais tarefas de 1 Gestor de Projecto.
2.5 Gestor de Projecto
A Gestão de um Projecto é frequentemente responsabilidade de um indivíduo
intitulado Gestor de Projecto. Idealmente, esse indivíduo raramente participa
directamente nas actividades que produzem o resultado final. Ele deve trabalhar
para manter o progresso e a interacção mútua dos diversos participantes do
empreendimento, de modo a reduzir o risco de fracasso do projecto. Ele deve ser
responsável por definir as metas e objectivos do projecto, determinar quando é que
os vários componentes do projecto devem ser executados e por quem, criando
assim um controlo de qualidade para garantir um certo padrão. É uma posição de
extrema importância no Projecto, as actividades mais importantes que o mesmo
deve desenvolver são:
42
Definir o Projecto e reduzi-lo a um conjunto de tarefas facilmente geridas,
obter os recursos apropriados e reunir uma equipa para desenvolver as
tarefas;
Definir o objectivo final do Projecto e motivar a sua equipa para a obtenção
desse objectivo no prazo e custo estipulado;
Deve informar os Stakeholders do progresso do Projecto regularmente;
Deve identificar e monitorar os riscos do Projecto e mitigar sobre os mesmos;
Nenhum projecto vai exactamente como planeado, os Gestores de Projecto
devem adaptar-se e gerir as mudanças;
O Gestor de Projectos deve ainda possuir muitas habilidades como:
Liderança;
Boa Comunicação (Verbal e Escrita);
Gestão de Pessoas (Clientes, Fornecedores, Gerentes Funcionais e Equipa
de Projectos);
Negociação;
Gestão de Conflitos;
Planeamento;
Gestão de Contractos;
Resolução de Problemas;
Boa gestão de tempo;
Pensamento Criativo
Estas são apenas algumas das habilidades que o mesmo deve possuir. O Gestor de
Projectos desempenha o papel mais importante dentro de um Projecto. A evolução
do Projecto e o seu sucesso dependem directamente do esforço que o mesmo
empenhar, deve acompanhar o desenvolvimento do Projecto desde o Princípio até
ao fim.
43
3. METODOLOGIA CIENTÍFICA
3.1. Considerações Iniciais
Para a elaboração deste trabalho foram utilizadas as seguintes metodologias:
Visitas;
Questionários;
3.2. Visitas
Foram realizadas 8 visitas às instalações da empresa, visitas essas que resultaram
em reuniões com os responsáveis de cada uma das áreas que a aplicação irá
abrangir. No fim de cada reunião, foram elaboradas actas para provar a existência
de tais reuniões.
3.2.1 Reunião 1
Realizada na data: 2011-08-10. A reunião foi realizada nas instalações da empresa
EPOLOMBO, onde estiveram presentes o Presidente da Empresa EPOLOMBO, o
senhor José António, o Director Geral da empresa Cachilimbichimue Soft e o Gestor
de Projectos, o senhor Edgar Patrício. Nesta reunião ficou acordado que o Software
será realizado no prazo de 3 meses (90 dias) e terá o custo total de 100000USD. Ver
acta da Reunião em Apêndice 1.
3.2.2 Reunião 2
Realizada na data: 2011-08-25. A reunião foi realizada nas instalações da empresa
EPOLOMBO, onde estiveram presentes o Presidente da Empresa EPOLOMBO, o
senhor José António e o Gestor de Projectos da empresa Cachilimbichimue Soft, o
senhor Edgar Patrício. Esta reunião serviu para o Gestor de Projectos disponibilizar
o Termo de Abertura e a Declaração de Escopo para aprovação da empresa
EPOLOMBO. Ver acta da Reunião em Apêndice 2.
44
3.2.3 Reunião 3
Realizada na data: 2011-09-10. A reunião foi realizada nas instalações da empresa
EPOLOMBO, onde estiveram presentes por parte da Empresa EPOLOMBO,o
Director da Logística, o Director Comercial(Vendas e Clientes), Director de
Marketing, Director Financeiro, Director Fabril e Director Informático. Por parte da
empresa Cachilimbichimue Soft estiveram presentes o Gestor de Projectos, o
Administrador de Base de Dados e o Analista Sénior de Software. Esta reunião
serviu para dar a conhecer o objectivo do projecto ao responsável de cada área e
garantir total suporte de todos eles para o desenvolvimento do Projecto. Ficou
também o compromisso de disponibilização de toda a informação de vendas,
Compras, Clientes, Fornecedores, Utilizadores e dados Financeiros por parte dos
Directores. Ver acta da Reunião em Apêndice 3.
3.2.4 Reunião 4
Realizada na data: 2011-09-15. A reunião foi realizada nas instalações da empresa
EPOLOMBO, onde estiveram presentes por parte da Empresa EPOLOMBO,o
Director da Logística, o Director Comercial(Vendas e Clientes), Director de
Marketing, Director Financeiro e Director Fabril. Por parte da empresa
Cachilimbichimue Soft estiveram presentes o Gestor de Projectos, o Administrador
de Base de Dados e o Analista Sénior de Software. Esta reunião serviu para
distribuição dos Questionários para obtenção dos parâmetros das várias áreas.
Estes questionários foram elaborados com base na informação histórica
disponibilizada pela empresa EPOLOMBO. Ver acta da Reunião em Apêndice 4.
3.2.5 Reunião 5
Realizada na data: 2011-10-12. A reunião foi realizada nas instalações da empresa
EPOLOMBO, onde estiveram presentes por parte da Empresa EPOLOMBO,o
Director Geral, o Director da Logística, o Director Comercial(Vendas e Clientes),
Director de Marketing, Director Financeiro e Director Fabril. Por parte da empresa
Cachilimbichimue Soft estiveram presentes o Gestor de Projectos, o Administrador
de Base de Dados, o Analista Sénior de Software e a equipa de desenvolvimento de
Software . Esta reunião serviu para Apresentação dos primeiros módulos (Clientes,
45
Fornecedores e Inventário) e consequente aprovação da empresa EPOLOMBO . Ver
acta da Reunião em Apêndice 5.
3.2.6 Reunião 6
Realizada na data: 2011-10-20. A reunião foi realizada nas instalações da empresa
EPOLOMBO, onde estiveram presentes por parte da Empresa EPOLOMBO,o
Director Geral, o Director da Logística, o Director Comercial(Vendas e Clientes),
Director de Marketing, Director Financeiro e Director Fabril. Por parte da empresa
Cachilimbichimue Soft estiveram presentes o Gestor de Projectos, o Administrador
de Base de Dados, o Analista Sénior de Software e a equipa de desenvolvimento de
Software . Esta reunião serviu para Apresentação dos restantes módulos (Vendas,
Compras, Contabilidade e Segurança) e consequente aprovação da empresa
EPOLOMBO . Ver acta da Reunião em Apêndice 6.
3.2.7 Reunião 7
Realizada na data: 2011-10-24. A reunião foi realizada nas instalações da empresa
EPOLOMBO, onde estiveram presentes por parte da Empresa EPOLOMBO,todos os
Directores. Por parte da empresa Cachilimbichimue Soft estiveram presentes o
Director Geral, o Gestor de Projectos e toda a equipa de Gestão de projectos . Esta
reunião serviu para Apresentação final do Projecto, bem como os últimos acertos .
Ver acta da Reunião em Apêndice 7.
3.2.8 Reunião 8
Realizada na data: 2011-11-02. A reunião foi realizada nas instalações da empresa
EPOLOMBO, onde estiveram presentes por parte da Empresa EPOLOMBO o
Director Geral. Por parte da empresa Cachilimbichimue Soft estiveram presentes o
Director Geral e o Gestor de Projectos. Esta reunião serviu para fecho do Projecto,
bem como acertos financeiros . Ver acta da Reunião em Apêndice 8.
3.3 Questionários
Foram elaborados 5 questionários para colecta de informação. Esses questionários
foram feitos com base nas informações fornecidas nas reuniões. Foi realizado um
questionário para cada módulo da aplicação.
46
3.3.1 Questionário de Clientes
Foi elaborado 1 questionário para Gestão de Clientes. O preenchimento deste
questionário ficou a cargo do Director Comercial. A partir da informação obtida neste
questionário será elaborada a informação dos clientes, os campos que deverão estar
na aplicação. Ver Questionário em Apêndice 9.
3.3.2 Questionário de Inventário
Foi elaborado 1 questionário para Gestão de Inventário. O preenchimento deste
questionário ficou a cargo do Director Financeiro. A partir da informação obtida neste
questionário será elaborada a informação dos Produtos e Inventário em Geral. Ver
Questionário em Apêndice 10.
3.3.3 Questionário de Compras
Foi elaborado 1 questionário para Gestão de Compras. O preenchimento deste
questionário ficou a cargo do Director Logistico. A partir da informação obtida neste
questionário será elaborada a informação das Compras. Ver Questionário em
Apêndice 11.
3.3.4 Questionário de Fornecedores
Foi elaborado 1 questionário para Gestão de Fornecedores. O preenchimento deste
questionário ficou a cargo do Director Logistico. A partir da informação obtida neste
questionário será elaborada a informação dos Fornecedores. Ver Questionário em
Apêndice 12.
3.3.5 Questionário de Vendas
Foi elaborado 1 questionário para Gestão de Vendas. O preenchimento deste
questionário ficou a cargo do Director Comercial. A partir da informação obtida neste
questionário será elaborada a informação de Vendas. Ver Questionário em Apêndice
13.
47
4. PLANO DE PROJECTO
4.1. Considerações Iniciais
Neste capítulo será apresentado o Plano de Projecto desenvolvido ao longo do
MBA. O mesmo será dividido em 9 subplanos menores.
4.2. Plano De Gestão de Escopo
O Plano de Gestão de Escopo do projecto inclui os processos necessários para
assegurar que o projecto inclui todo o trabalho necessário, e apenas o necessário,
para terminar o projecto com sucesso. Essa gestão está relacionada principalmente
com a definição e controle do que está e do que não está incluso no Projecto. (Guia
PMBOK, 2008)
O plano de Gestão de Escopo engloba:
Colectar os requisitos
o Termo de Abertura do Projecto;
o Lista de Requisitos;
o Premissas
Definição do Escopo
Criar a EAP/WBS;
o EAP;
o Dicionário de EAP;
Na figura 8, é possivel observar os processos da Gestão do escopo do Projecto e as
suas Entradas, ferramentas e técnicas e saídas. Sendo que os três primeiros
(Colectar os Requisitos, Definir o Escopo e Criar a EAP) fazem parte dos processos
de Planeamento e os dois últimos (Verificar o Escopo e Controlar o Escopo) fazem
parte dos processos de Monitoramento e controle.
48
Figura 8 - Visão Geral da Gestão do Escopo do Projecto segundo o Guia PMBOK 2008
4.2.1 Termo de Abertura
4.2.1.1 Justificativa do Projecto
A empresa EPOLOMBO Lda. é uma empresa de venda de Refrigerantes e Produtos
alimentícios. Nos últimos meses o seu negócio tem aumentado de forma
exponencial, aumentando não só o volume de vendas, mas também as áreas de
vendas, difundindo-se em todas as Províncias do país.
Tendo em conta este crescimento e necessidade de melhor controlar o seu negócio,
a empresa EPOLOMBO Lda. decidiu reunir com a Direcção da Empresa
Cachilinguichimue Soft para o desenvolvimento de 1 Software de Gestão que
49
englobe apenas os seguintes módulos: Inventário, Clientes, Fornecedores,
Contabilidade, Vendas e Compras. Isto porque a empresa não tem nenhum Software
para gerir o seu negócio. Não tendo ferramentas para gerir o negócio e obter
relatórios de vendas, a probabilidade de fraude e perdas é muito grande.
4.2.1.2 Descrição do Produto do Projecto
Consiste no desenvolvimento de um Software de gestão (Cachilinguichimue Soft)
para adaptação do negócio da empresa EPOLOMBO Lda que englobe apenas os
seguintes módulos: Inventário, Clientes, Fornecedores, Contabilidade, Vendas e
Compras.
4.2.1.3 Designação do Gerente de Projecto
O Sr. Edgar Patricio, será o gerente deste projecto. Sua escolha foi realizada em
razão de sua experiência e idoneidade no desenvolvimento de outros softwares
dentro da organização.
4.2.1.4 Premissas (hipóteses) e restrições para o Projecto
A tabela 1 tem a lista de Premissas, que são hipóteses, ou seja, algo que não
depende directamente da equipa de projectos mas que deverá ser levado em
consideração pelos mesmos e a lista de restrições que deverá obrigatoriamente ser
respeitada pela equipa de Projectos.
Premissas (hipóteses) Restrições
-Será disponibilizada uma sala com
computadores ligados a rede pelo
Sponsor para a equipa poder fazer os
testes no site.
-Serão disponibilizados pelo Sponsor
“Passes de acesso” as fábricas e lojas
da empresa EPOLOMBO para os
programadores poderem conhecer o
negócio.
-A aplicação deverá ser desenvolvida
num prazo de 3 meses (90 dias).
-O Orçamento não deverá ultrapassar
os 100000USD.
-A base de dados deverá ser feita em
SQL;
-A linguagem de programação será o
C#.
-A aplicação deverá correr apenas em
50
-Serão disponibilizados pela Empresa
EPOLOMBO a lista de clientes,
fornecedores, produtos etc.
ambiente Windows.
- Só terá os seguinte módulos:
Inventário, Clientes, Fornecedores,
Contabilidade, Vendas e Compras
Tabela 1 – Lista de Premissas e Restrições do Projecto
4.2.1.4 Lista de Requisitos do Produto
A lista de requisitos do Produto indica o que o Produto deve possuir. Para que a sua
entrega possa ser considerada é necessário que o Produto possua todos os
requisitivos estabelecidos na Tabela 2.
Lista de Requisitos do Produto
Emissão de Relatórios: A aplicação deve ser capaz de emitir relatórios de suporte
fáceis.
User Friendly: Pelo facto de 90% dos users ter pouco contacto com os
computadores, é exigido que a aplicação seja de fácil manuseio e seja user
friendly.
Facilidade para deficientes: A aplicação deverá ter opções de utilização por parte
de deficientes físicos, como teclas de atalho etc
Globalização: A aplicação deverá dar ao utilizador a possibilidade de escolher
entre 3 línguas: Português, Inglês e Kimbundo.
Web e Stand Alone: A Aplicação terá a facilidade de poder ser utilizada via
Browser ou Stand Alone.
Duração da Informação: Pela lei angolana, a informação contabilística deve poder
ser visualizada num período de 5 anos. O Software poderá guardar informação até
10 anos, sendo que a restante informação será armazenada em Backups.
Acesso Remoto: A empresa Epolombo tem fábricas e lojas em todas as
Províncias de Angola, sendo assim, o Software será usado em Rede WAN com
acesso remoto ao servidor em todas as províncias.
Segurança: Por estar a lidar com informação confidencial, o software deverá ter 1
51
nível de segurança muito alta, tanto na informação, como nos níveis de acesso que
poderão ser atribuídos aos Utilizadores aos vários módulos e programas.
Portabilidade: Pelo facto de o nosso país ainda possuir pontos sem acesso à
Internet, a aplicação deverá funcionar em Offline, onde o utilizador poderá registar
vendas, compras, transferências etc sem estar conectado à base de dados e
posteriormente sincronizar os dados.
Informação/Ajuda: O software deverá ter 1 módulo de Ajuda prático e fácil para o
Utilizador, com manuais, ilustrações, exemplos etc.
Tabela 2 – Lista de Requisitos
4.2.1.5 Matriz de Rastreabilidade
A Matriz de Rastreabilidade é montada através da lista de Requisitos. Para cada
requisito será descrito o proprietário, ou seja, o responsável pelo cumprimento do
Requisito, a fonte, que indica de onde o requisito foi recolhido, a prioridade
(alta,média ou baixa) que pode ser sumarizada em escalas (exemplo: de 1 a 5), a
versão do requisito, para poder-se acompanhar as mudanças feitas ao requisito, o
Status do Requisito e a Data prevista para a conclusão desse requisito.Ver em
Anexo XX, tabela 3.
4.2.2 Declaração de Escopo
4.2.2.1 Justificativa do Projecto
(Ver sessão 4.2.1.1)
4.2.2.2 Descrição do Produto de Projecto
(Ver sessão 4.2.1.2)
4.2.2.3 Estratégias de Condução do Projecto
A criação do software será de excluvisivade para gestão da empresa EPOLOMBO
Lda. E terá como mais valia após a sua implementação desde os testes até a
utilização a capacidade de eliminar o uso de interfaces manuais, Reduzir os custos,
Optimizar o fluxo da informação e a qualidade da mesma dentro da organização
52
(eficiência), Optimizar o processo de tomada de decisão, Eliminar a redundância de
actividades, Reduzir os lead times e tempos de resposta ao mercado. Para isto,
deverá o projecto ser gerido em seguintes fases:
Raio x
Desenvolvimento
Teste
Treinamento
Implantação
Avaliação
4.2.2.4 Lista das Principais entregas
Base de dados
Tabela e chaves
Preechimento de tabela auxiliares
Indexação
Consulta de scrips
Politicas de backup
Formulários/janelas
Relatórios
Métodos e funções
Conexão
Plano de teste de software
Caso de teste do software
Resultado dos testes do software
Aceitação dos testes do software
Correcção de BUGS
Treinamento
Suporte
Termo de encerramento
Lições aprendidas
Desmembramento.
53
4.2.2.5 Critérios de aceitação do Produto
Para que o Produto(Software) seja aceite pelo cliente, deve obedecer um conjunto
de padrões que são:
Possuir todos os requisitos descritos na tabela 2;
Ser entregue dentro do prazo estipulado de 3 meses (90 dias);
Não ultrapassar o Orçamento de 100000USD;
Atingir 100% de sucesso nos testes do Produto;
Ter 70% da empresa formada e apta a usar o Software;
Ter uma política de Backups e recuperação de informação;
4.2.2.6 Exclusões do Projecto
Tão importante como definir o que o Projecto deve fazer é também definir o que o
mesmo não deve fazer, de forma a gerir as espectativas de todos os Stakeholders.
O produto em causa não deverá:
ser responsável pela Gestão de Recursos Humanos;
ter integração com outros softwares da empresa;
ter outra língua que não seja o inglês, português e kimbundo;
ter integração com Servidores de Email ou SMS;
correr em outros ambientes que não seja o Windows(XP,Vista etc);
fazer o fecho de contas de forma automática;
4.2.2.7 Equipa de Planeamento do Projecto
A equipe de planeamento do projecto é constituída por:
Gerente do Projecto: Edgar Patrício
Representante da Direcção de Marketing: Manuel Ribeiro
Representante da Direcção de Informática: António Peixoto
Representante da Direcção Geral: Flavia Cunha
Consultor contractado em Gerenciamento de Projectos: Carlos Martins
54
4.2.3 Criar a EAP
Criar a EAP é o processo de subdivisão das entregas e do trabalho do projecto em
componentes menores e de gestão mais fácil.
4.2.3.1 Estrutura Analítica do Projecto (EAP)
A Estrutura Analítica do Projecto (EAP) é uma decomposição hierárquica orientada
às entregas do trabalho a ser executado pela equipa para atingir os objectivos do
projecto e criar as entregas requisitadas, sendo que cada nível descendente da EAP
representa uma definição gradualmente mais detalhada da definição do trabalho do
projecto. A EAP organiza e define o escopo total e representa o trabalho
especificado na actual declaração do escopo do projecto. (Guia PMBOK, 2008) No
Anexo XX, Figura YY pode ver a EAP do Projecto em questão.
4.2.3.2 Dicionário da EAP
O dicionário da EAP é um documento gerado pelo processo de criar a EAP que a
suporta. Fornece descrições mais detalhadas dos componentes da EAP, inclusive
dos pacotes de trabalho e contas de controle. (Guia PMBOK, 2008). No Anexo XX,
Figura YY pode ver o Dicionário da EAP do Projecto em Questão.
4.2.4 Verificar o Escopo
Verificar o escopo é o processo de formalização da aceitação das entregas
concluídas do projecto. Inclui a revisão das entregas com o cliente ou patrocinador
para assegurar que foram concluídas satisfatoriamente e obter deles a aceitação
formal das mesmas. A verificação do escopo difere do controle de qualidade, pois
está interessada principalmente na aceitação das entregas, enquanto que o segundo
se interessa com a precisão das mesmas e o alcance dos requisitos de qualidade
especificados para elas. O Controlo da qualidade é geralmente efectuado antes da
verificação do Escopo, mas os dois processos podem ser executados em paralelo.
(Guia PMBOK, 2008). Colocar documentos que ilucidam a verificação do
escopo.
55
4.2.5 Controlar o Escopo
É o processo de monitaramento do andamento do escopo do projecto e do produto e
gestão das mudanças feitas na linha de base do escopo. O controle do escopo do
projecto é usado também para gerir as mudanças reais quando essas ocorrerem e é
integrado aos outros processos de controle. (Guia PMBOK, 2008).
56
4.3 Plano de Gestão de Tempo
O Plano de Gestão de Tempo inclui os processos necessários para gerir o término
pontual do Projecto. Na figura 9, é possivel observar os processos da Gestão de
Tempo com as entradas, ferramentas e técnicas e saídas.
Figura 9 - Visão Geral da Gestão do Tempo do Projecto segundo o Guia PMBOK 2008
57
4.3.1 Definir as actividades
Definir as actividades é o processo de identificação das acções especificas a serem
realizadas para produzir as entregas do projecto. O Processo Criar a EAP identifica
as entregas no nível mais baixo da estrutura analítica do Projecto (EAP), o pacote de
trabalho. Esses pacotes são tipicamente decompostos em componentes menores
chamados actividades que representam o trabalho necessário para completar o
pacote de trabalho. As actividades proporcionam uma base para a estimativa,
desenvolvimento do cronograma, execução e monitoramento e controle do trabalho
do projecto. (Guia PMBOK, 2008). No Anexo XX, Tabela 5 é possível ver-se as
actividades do Projecto em Questão.
4.3.2 Sequenciar as actividades
Sequenciar as actividades é o processo de identificação e documentação dos
relacionamentos entre as actividades do projecto. As mesmos são sequenciadas
usando relações lógicas. Cada actividade e marco, com excepção do primeiro e do
último, são conectados a pelo menos um predecessor e um sucessor. O uso de
tempo de antecipação ou de espera pode ser necessário entre as actividades para
dar suporte a um cronograma de projecto realista e executável. (Guia PMBOK,
2008). No Anexo XX, Tabela 6 é possível ver-se a sequência das actividades do
Projecto em Questão.
4.3.3 Estimar os Recursos das actividades
Estimar os Recursos das actividades é o processo de estimativa dos tipos e
quantidades de material, pessoas, equipamentos ou suprimentos que serão
necessários para realizar cada actividade. . (Guia PMBOK, 2008). No Anexo XX,
Tabela 7 é possível ver-se a os Recursos das actividades do Projecto em Questão.
4.3.4 Estimar as durações das actividades
Estimar as durações das actividades é o processo de estimativa do número de
períodos de trabalho que serão necessários para terminar as actividades específicas
com os recuros estimados. A estimativa das durações das actividades utiliza
informações sobre as actividades do escopo do projecto, tipos de recursos
58
necessários, quantidades estimadas de recursos e calendários de recursos. (Guia
PMBOK, 2008). No Anexo XX, Tabela 8 é possível ver-se as estimativas das
durações das actividades do Projecto em Questão.
4.3.5 Diagrama de Redes
O Diagrama de Redes serve para indicar de forma gráfica a sequencia e duração
das actividades, determinando o caminho crítico (caminho sem folgas) e as folgas do
projecto.
Figura 10 - Diagrama de Redes do Projecto
O projecto deverá estar concluído dentro de 92 dias desde o seu começo.
Legenda:
Amarelo Código Actividade
Cinzento Caminho Crítico
1º Quadrado superior
esquerdo
Começo mais cedo
59
2º Quadrado Duração da actividade em dias
3º Quadrado Término mais cedo
1º Quadrado inferior
esquerdo
Começo mais tarde
2º Quadrado inferior Duração da actividade em dias
3º Quadrado inferior Término mais tarde
Tabela XX – Legenda do Diagrama de Redes
60
4.4 Plano de Gestão de Custos
O Plano de Gestão de Custos do projecto inclui os processos envolvidos em
estimativas, orçamentos e controle dos custos, de modo que o projecto possa ser
terminado dentro do orçamento aprovado. (Guia PMBOK, 2008)
Figura 11 - Visão Geral da Gestão de Custos do Projecto segundo o Guia PMBOK 2008
4.4.1 Estimar os custos
Estimar os custos é o processo de desenvolvimento de uma estimativa dos recursos
monetários necessários para executar as actividades do Projecto. Para determinar
as actividades do projecto foi usada a EAP (Figura XX), onde estão listadas todas as
entregas do Projecto. Em paralelo foram também usados o cronograma (Figura XX),
o Plano de Recursos Humanos (Sessão XX) para estimar o tempo e recursos
existentes em cada actividade e o Registo de Riscos (Figura XX). Para estimar os
custos usou-se a Estimativa análoga, usando valores de parâmetros (escopo,
61
custo, duração) de projectos anteriores semelhantes, pois a empresa possui um
grande portfólio de projectos similares.
1 Planeamento 19.000,00
1.1 - Levantar Informações 5.000,00
1.2 - Preparar Esboço 3.000,00
1.3 - Revisar Entendimento 1.000,00
1.4 - Preparar Plano 10.000,00
2 Execução 15.000,00
2.1 - Desenvolvimento 7.500,00
2.2 - Testes 7.500,00
3 Entrega 8.500,00
3.1 - Implantação 2.000,00
3.2 - Testes 1.500,00
3.3 - Treinar usuários 3.000,00
3.4 - Operação Assistida 2.000,00
CUSTO TOTAL DIRETO 42.500,00
Tabela X – Estimativa de Custos do Projecto
4.4.2 Determinar o orçamento
Determinar o orçamento é o processo de agregaçao dos custos estimados de
actividades individuais ou pacotes de trabalho para estabelecer uma linha de base
dis custos autorizada. Essa linha de base inclui todos os orçamentos autorizados.
WBS Planeamento 19.000,00
1.1 - Levantar Informações 5.000,00
1.2.1 - Requisitos do Software 3.000,00
1.2.3 - Requisitos de Hardware 1.000,00
1.2.2 - Documentação para Usuários 500,00
1.2.4 - Implementação e suporte 9.000,00
1.2.5 - Material para treino 500,00
WBS Execução 15.000,00
1.3.1 - Desenho de Casos de Uso 1.500,00
1.3.2 - Desenho da arquitectura de dados 1.000,00
1.3.3 - Desenho da arquitectura de Hardware 1.000,00
1.3.4 - Desenho da interface gráfica 1.000,00
62
1.3.5 - Desenho dos objectos 1.000,00
1.3.6. - Desenho dos Workflows 1.000,00
1.3.7 - Desenho das regras 1.000,00
1.3.8 - Desenho da base de dados 1.500,00
1.4.1 - Desenvolvimento da base de dados 2.000,00
1.4.2 - Desenvolvimento da camada de apresentação 2.000,00
1.4.3 - Desenvolvimento da camada intermediária 1.000,00
1.4.4 - Desenvolvimento da camada de dados 1.000,00
WBS Entrega 8.500,00
1.6 - Implantação (Go Live) 2.000,00
1.5 - Testes 1.500,00
1.7.1 - Treinar usuários 3.000,00
1.7.2 - Operação Assistida 2.000,00
CUSTO TOTAL DIRETO 42.500,00
Tabela X – Orçamento das actividades do Projecto (sem recursos)
Depois de calcular o custo das actividades do Projecto sem estimar o custo dos
recursos, foi calculado o custo dos recursos humanos do Projecto.
Tipo de Profissional Número de
Recursos
Carga Horária
Custo Hora
Custo Profissional
Programador Sénior 1 100 20 2.000,00
Programador Junior 2 100 15 3.000,00
Analista Sénior 1 150 15 2.250,00
Analista Júnior 1 150 12 1.800,00
Administrador de BD 1 60 30 1.800,00
Administrador de Aplicações 1 50 20 1.000,00
Instrutor 1 50 10 500
Documentador 1 20 12 240
Gerente de Projetos 1 250 35 8750
TOTAL CARGA HORÁRIA 10 930 169 21.340,00
Tabela XX- Custo dos Recursos Humanos do Projecto
63
Tipo de Recurso Número de Recursos Custo Unitário (USD)
Custo Total
Labtop 10 700 7.000,00
Servidor de Base de dados
1 5000 5.000,00
Servidor de Aplicações 1 4500 4.500,00
Router 1 500 500,00
Switch 1 500 500,00
Cabo de rede 10 35 350,00
Impressora 1 200 200,00
Scanner 1 150 150,00
TOTAL 18.200,00
Tabela X – Custo dos Recursos Materiais do Projecto
Para além destes custos foi ainda adicionado uma reserva de contigência no valor
de 10000USD. Esta reserva será usada caso algum dos riscos identificados no
Projecto (Sessão 4.8 – Plano de Gestão de Riscos) aconteça. Na tabela XX é
possível verificar o custo total do Projecto.
Tipo de Custo Valor
Orçamento das actividades do Projecto 42.500,00
Custo dos recursos humanos do Projecto 21.340,00
Custo dos recursos materiais do Projecto 18.200,00
Reserva de contigência 10.000,00
Total 92.040,00
Tabela X – Orçamento Total do Projecto
4.4.3 Controlar os custos
Controlar os custos é o processo de monitoramento do progresso do projecto para
actualização do seu orçamento e gestão das mudanças feitas na linha de base dos
custos. A actualização do orçamento envolve o registo dos custos reais gastos até a
data. Qualquer aumento do orçamento autorizado somente pode ser aprovado
64
através do processo de controle integrado de mudanças. O controlo de custos do
projecto inclui:
Influenciar os factores que criam mudanças na linha de base de custos
autorizada;
Assegurar que todas as solicitações de mudança sejam feitas de maneira
oportuna;
Gerir as mudanças reais conforme ocorrem;
Assegurar que os gastos de custos não excedam os recursos financeiros
autorizados, por período e total do projecto;
Monitorar o desempenho de custos para isolar e entender as variações a
partir da linha de base de custos;
Monitorar o desempenho do trabalho em relação aos recursos financeiros
gastos;
4.8 Plano de Gestão de Riscos
O Plano de Gestão de Riscos inclui os processos de planeamento, identificação,
análise, planeamento de respostas, monitoramento e controle de riscos de um
projecto. Os objectivos da gestão de riscos são aumentar a probabilidade e o
impacto dos eventos positivos e reduzir a probabilidade e o impacto dos eventos
negativos no projecto. (Guia PMBOK, 2008). Na Figura XX é possivel observar os
65
Processos da Gestão de Riscos, com as respectivas entradas, ferramentas e
técnicas e saídas.
4.8.1 Planear a Gestão dos Riscos
Nesta sessão, será apresentado o Plano de Gestão de Riscos. O Plano de Gestão
de Riscos é o guia para identificação, análise e resolução dos riscos do projecto,
dizendo quem deverá identificar e analisar os riscos, como fazê-lo e com que
66
frequência. Tentando maximizar a probabilidade de ocorrência de eventos positivos
e minimizar os eventos negativos ao projecto.
Tem como propósito provocar os gerentes de projecto a pensar de forma organizada
e metódica no que diz respeito a gestão de riscos e proporcionar uma infra-estrutura
organizacional para suportá-los. Tem como entrada os Factores ambientais da
empresa, activos de processos organizacionais, declaração do escopo do projecto e
plano de Gestão do projecto. Tem como saída o próprio plano de Gestão de Riscos
De sequida serão descritos os seguintes processos:
Identificação dos Riscos;
Avaliação Qualitativa dos Riscos;
Avaliação Quantitativa dos Riscos;
Planeamento de respostas aos riscos;
Monitoramento e Controle dos Riscos;
4.8.1.1 EAR
A EAR (Estrutura Analítica dos Riscos) revela-se extremamente valiosa para
compreender melhor quando um projecto precisa receber um escrutínio especial, em
outras palavras, quando o risco pode acontecer. A EAR também pode ajudar o
gerente de projecto e o gerente de riscos a compreenderem melhor os riscos
recorrentes e concentrações de risco que podem levar a problemas que afectam o
status do projecto. Na Figura XX pode-se observar a EAR do Projecto:
67
Figura ?? - EAR (Estrutura Analitica de Riscos
4.8.2 Identificar os Riscos
A identificação dos riscos é uma fase fundamental no processo de gestão de riscos
pois permite tornar conhecido os riscos que podem afectar os objectivos do projecto;
a mesma deve ocorrer em várias etapas:
Podem ser incluídos todos os integrantes da equipe do projeto,
os interessados,
os especialistas nos assuntos,
usuários e quem puder ajudar no processo.
É possível que na primeira fase da identificação dos riscos, esteja
68
incluída apenas a equipe do projeto e depois sejam acrescentados
os interessados ou a equipe do gerenciamento de riscos para ajudar
ainda mais durante a fase seguinte.
Para identificação dos riscos inerentes ao projecto utilizou-se a técnica de
Brainstorming que consiste na discussão em grupo para maximizar as ideias, pois a
probabilidade de encontrarmos soluções é maior por ter-se mais pessoas
envolvidas, bem como a técnica de SWOT para identificar as fraquezas,
oportunidades, forças e ameaças;
No Anexo XX, na tabela YY pode-se observar os 29 riscos identificados no Projecto.
4.8.3 Análise Qualitativa e Quantitativa
Nesta sessão serão descritas as análises Quantitativa e Qualitativa do Risco do
nosso projecto.
4.8.3.1 Análise Qualitativa
Análise qualitativa de risco é o processo de avaliação do impacto e probabilidade de
riscos identificados. Este processo prioriza riscos de acordo com os seus efeitos
potenciais nos objectivos do projecto. Análise qualitativa de risco é um modo de
determinar a importância de se endereçar riscos específicos e guiar respostas de
risco. A questão crítica do tempo e as acções relacionadas ao risco podem ampliar a
importância de um risco. Uma avaliação da qualidade da informação disponível
também ajuda a modificar a avaliação do risco. Análise qualitativa de risco requer
que a probabilidade e consequências dos riscos sejam avaliadas usando métodos e
ferramentas de análise qualitativa estabelecidos. Tendência nos resultados quando
a análise qualitativa é repetida pode indicar a necessidade de mais ou menos acção
da gerência de risco. O uso dessas ferramentas ajuda a corrigir influências que
estão frequentemente presentes em um plano de projecto. Análise qualitativa de
risco deve ser re-visitada durante o ciclo de vida do projecto para que fique
actualizado às mudanças dos riscos do projecto. Este processo pode levar a análise
quantitativa de risco mais adiante ou directamente ao planeamento de resposta de
risco.
69
4.8.3.2 Análise Quantitativa
O processo de análise quantitativa de risco tem como objectivo analisar
numericamente a probabilidade de cada risco e de sua respectiva consequência nos
objectivos do projecto, assim como a extensão do risco geral do projecto. Este
processo usa técnicas tais como a simulação de Monte Carlo e análise de decisão
para:
Determinar a probabilidade de se conquistar um objectivo específico do
projecto.
Quantificar a exposição do risco para o projecto, e determinar o tamanho da
reserva contingência do custo e cronograma que pode ser necessária.
Identificar riscos que requerem maior atenção, quantificando sua
contribuição relativa ao risco do projecto.
Identificar custo, cronograma, ou objectivos de escopo realístico e
alcançável.
Análise quantitativa de risco geralmente segue a análise qualitativa de risco. Ela
requer a identificação de risco. Os processos de análise quantitativa e qualitativa de
risco podem ser usados separadamente ou juntos. Considerações com relação a
disponibilidade de tempo e orçamento e a necessidade para declarações qualitativas
ou quantitativas sobre risco e impactos determinarão que método(s) usar.
Tendências nos resultados quando a análise quantitativa é repetida pode indicar a
necessidade de mais ou menos acção de gerenciamento de risco.
Depois de identificados todos os riscos do Projecto, o primeiro factor é encontrar a
probabilidade desses riscos ocorrerem. Para tal, foi utilizada uma escala de
0.05(Desprezivel) a 0.8 (Muito Alto) como se pode ver na tabela abaixo.
Figura zzz
70
É muito importante determinar-se a probabilidade de ocorrência de cada evento de
risco, pois irá ajudar na resposta que deverá ser dada ao risco, riscos com
probabilidade muito alta de ocorrência devem ter um tratamento especial, pois é
quase certo que os mesmos irão ocorrer. Os mecanismos de resposta a esse risco
devem ser os mais eficazes possíveis.
O segundo ponto a ter em atenção é o impacto do risco sobre o projecto. Identificou-
se o impacto do risco sob 4 vertentes importantes do projecto:
Escopo: Permite identificar e quantificar o impacto que determinado risco irá ter
sobre o escopo do projecto;
Custo: Permite identificar e quantificar o impacto que determinado risco irá ter sobre
o custo do projecto;
Tempo: Permite identificar e quantificar o impacto que determinado risco irá ter
sobre o tempo do projecto;
Qualidade: Permite identificar e quantificar o impacto que determinado risco irá ter
sobre a qualidade do projecto;
Para quantificar o impacto do risco sobre os 4 itens descritos, usamos medidas
mensuráveis de 0,05 (Desprezível) a 0,8 (Muito Alto), espelhando assim qual o real
impacto do risco sobre o projecto.
Figura xxxx
71
Tendo achado estas duas medidas, podemos identificar a Severidade do risco, que
não é mais do que o produto da Probabilidade pelo Impacto. Uma vez que utilizamos
4 variáveis de impacto, iremos utilizar a variável de maior valor. Sendo assim, a
severidade do risco será Probabilidade x Max(Impacto).
Depois de calculada a severidade podemos calcular a prioridade do risco,
normalmente riscos com severidade alta terão uma prioridade maior e riscos com
severidade mais baixa terão menor prioridade. Para facilitar a percepção, dividiu-se
a escala de prioridade em 4 itens:
1 – Baixa
2 – Média
3 - Alta
Depois de identificados os riscos, calcular Probabilidade, Impacto, Severidade e
Prioridade podemos calcular a urgência e o dono/responsável pelo risco. Definimos
urgência como o número de dias que se deverá levar para a resolução do risco. Esta
urgência deve ter em conta a Severidade e Prioridade definidas anteriormente.
Devemos então atribuir 1 responsável ou responsáveis da equipa a esse risco. Esse
(s) responsável (eis) devem possuir “know how” suficiente para resolver o risco caso
o mesmo ocorra. Deve ser 1 especialista nessa área ou saber apontar um
especialista para ajudar a resolver o risco.
Podemos agora definir a data limite para resolução do risco, bem como o
gatilho/trigger desse risco. Os Triggers são indicativos de que a probabilidade do
risco acontecer é maior. Devemos ter meios ou medidas que nos indiquem que
estamos na eminência desse risco acontecer, para que o plano de resposta ao risco
seja posta em prática. Veja o Registo dos riscos com respectiva análise Qualitativa e
Quantitativa no Anexo XX, tabela YY.
4.8.4 Planear as respostas aos Riscos
O plano de resposta ao risco é o processo de desenvolvimento de opções e
determinação das acções para melhorar oportunidades e reduzir ameaças para os
72
objectivos do projecto. Ele inclui a identificação e designação de indivíduos ou
partes, com a responsabilidade para cada acordo de resposta ao risco. Este
processo assegura que riscos identificados são devidamente endereçados. A
eficácia do planeamento de resposta determinará directamente se risco do projecto
cresce ou diminui. O plano de resposta ao risco deve ser apropriado para a
severidade do risco, estimando um custo real, o tempo necessário para ser bem
sucedido, dentro de um contexto realístico, acordado por todas as partes envolvidas
e designado um responsável. Frequentemente é requerida a selecção da melhor
resposta dentro das várias opções.
Como entrada do plano de resposta ao risco temos o próprio plano de gestão de
riscos, a identificação dos riscos, as análises quantitativa e qualitativa,
probabilidades, severidade, prioridade, urgência e donos dos riscos.
Foram utilizadas 4 estratégias de respostas aos riscos identificados, nomeadamente:
1 Evitar.
Evitar o risco é mudar o plano de projecto para eliminar o risco ou a condição, ou
para proteger os objectivos do projecto destes impactos. Embora a equipe não
possa eliminar todos os eventos de risco, alguns riscos específicos podem ser
evitados.
Alguns eventos de risco que surgem cedo no projecto podem ser evitados com
requerimentos esclarecedores, obtendo-se informações, melhorando a comunicação
ou consultando especialista. Reduzindo escopo para evitar actividades de alto risco,
acrescentando recursos ou tempo, adoptando uma abordagem familiar em vez de
uma inovação, ou evitando um fornecedor desconhecido podem ser exemplos de
evitar o risco.
2 Transferir.
Transferir o risco é procurar mudar a consequência de um risco para uma terceira
parte junto com a responsabilidade da resposta. Transferindo o risco simplesmente
daremos a outra parte a responsabilidade para gerir isto; isto não o elimina.
Transferir a responsabilidade do risco é a mais eficaz nas transacções com risco de
exposição financeira. Transferir risco quase sempre envolve pagamentos de um
73
valor para que a terceira parte assuma este risco. Ele inclui o uso de seguro, bônus
de desempenho, garantias e comprovação. Podem ser usados contratos para
transferir responsabilidade para riscos específicos para outra parte. O uso de
contrato de preço fixo pode transferir o risco para o fornecedor se o design do
projecto não sofrer modificação. Embora um contrato de reembolso de custo deixe o
risco mais com o cliente ou patrocinador, ele pode auxiliar a redução do custo se
existir mudanças no meio do projecto.
3 Mitigar.
A mitigação procura reduzir a probabilidade e/ou consequências de um evento de
risco de adverso para um aceitável. Tomar acções cedo para reduzir a probabilidade
de uma ocorrência ou impacto no projecto é mais eficaz que tentar reparar as
consequências depois de ocorrido. A mitigação de custos deve ser apropriada,
dando a provável probabilidade do risco e suas consequências.
A mitigação de risco pode tomar a forma de implementação de um novo curso de
acção que reduzirá o problema—ex.: adoptando processos menos complexos,
conduzindo mais testes sísmico ou de engenharia, ou escolhendo fornecedor mais
estável. Ele pode envolver condições de mudanças em que a probabilidade de
ocorrência de risco seja reduzida—ex. adicionando recursos ou tempo no
cronograma. Ele pode requer o desenvolvimento de protótipo com escala menor
para reduzir o risco.
Aonde não é possível reduzir a probabilidade, a mitigação da resposta pode
endereçar o impacto do risco para determinar a severidade. Por exemplo,
desenhando redundâncias no subsistema pode reduzir o impacto que resultem de
falhas de um componente original.
4 Aceitar.
Esta técnica indica que a equipe do projecto decidiu não trocar o plano do projecto
para negociar com um risco ou não é possível fazer algo para identificar alguma
outra estratégia de resposta apropriada. A aceitação activa pode incluir desenvolver
um plano de contingência para executar quando ocorrer um risco. A aceitação
passiva não requer acção, deixando a equipe de projecto fazer um arranjo quando o
74
risco ocorrer.
Um plano de contingência é aplicado para riscos identificados que surjam durante o
projecto. Desenvolvendo um plano de contingência antecipadamente pode-se
reduzir enormemente o custo de uma acção quando ocorrer o risco. Detonadores de
risco, assim como ausência de milestones intermediários, devem ser definidos e
acompanhados. Um plano de retrocedimento é desenvolvido se o risco tem um alto
impacto, ou se a estratégia seleccionada não for totalmente eficaz. Este pode incluir
alocação de uma quantia de contingência, opções de desenvolvimento alternativo,
ou mudanças no escopo do projecto. A mais comum resposta de aceitação do risco
é estabelecer uma ajuda de custo de contingência ou reserva, incluindo quantidades
de tempo, dinheiro, ou recursos para cobrir o risco. A ajuda de custo deve ser
determinada pelo impacto computado em um nível de exposição de risco aceitável,
para o risco que tem de ser aceite.
4.8.5 Monitoramento e Controle dos Riscos
Monitoramento e controle do risco é o processo de identificar e de assegurar o
controle do risco, monitorando riscos residuais e identificando novos riscos,
assegurando a execução dos planos do risco e avaliando sua eficiência na redução
dos riscos. Monitoramento e controle do risco regista as métricas que estão
associadas com planos de contingência. Monitoramento e controle do risco é um
processo contínuo para o ciclo de vida do projecto. Os riscos mudam como as
maturidades do projecto, desenvolvem novos riscos ou antecipam o
desaparecimento de riscos.
Bons processos de monitoramento e controle do risco fornecem informações que
suportam com decisões eficazes o que fazer no avanço de ocorrências dos riscos.
Comunicações para todas as partes envolvidas são necessárias para avaliar
periodicamente a aceitabilidade do nível de risco no projecto.
A proposta de monitoramento de risco é para determinar se:
As respostas ao risco estão sendo implementadas como planejadas.
Acções de respostas ao risco estão eficazes como esperadas ou se novas
respostas devem ser desenvolvidas.
As hipóteses ainda são válidas.
75
Análise de tendências da exposição do risco tem mudado prioridades.
Ocorreu um detonador do risco.
As políticas e procedimentos adequados estão sendo seguidos.
Têm ocorrido ou surgido riscos que não foram identificados anteriormente.
Controle de risco pode envolver escolha de alternativas estratégicas,
implementando um plano de contingência, tomando acções correctivas ou
replaneando o projecto. O dono da resposta ao risco deverá relatar periodicamente
para o gerente do projecto e para o líder da equipe a eficácia do plano, alguns
efeitos não previstos e alguma necessidade de correcção no curso para mitigar o
risco.
4.8.5.1 Revisões periódicas
Serão realizadas revisões periódicas para acompanhamento dos riscos identificados
e o plano de resposta ao mesmo. Uma reunião quinzenal será realizada para que
cada responsável de risco demonstre a evolução do plano de resposta ao seu risco.
Toda e qualquer alteração ou acréscimo ao Plano de Gestão de riscos deverá ser
aprovada pelo Gerente de riscos e passar por todo o processo desde a identificação,
análise qualitativa e quantitativa, probabilidade etc. O processo de gestão de riscos
é um ciclo, que deve ser revisto para garantir a sua perfeita execução.
4.8.5.2 Comunicação de riscos
Depois de cada reunião de revisão de riscos deverá ser elaborada uma acta dessa
reunião e enviada a todos os stakeholders. Toda e qualquer alteração, registo de
novos riscos ou mudança no plano de resposta será comunicada aos stakeholders.
4.8.5.3 Documentos para aprovação de riscos
Sempre que for necessário mudar ou acrescentar 1 novo risco deverá ser
preenchido o documento de mudança de riscos, que deverá ser posteriormente
aprovado pelo Gerente de Projectos. Ver o documento em anexo com o nome
“PLANO DE GERENCIAMENTO DE RISCOS.DOCX”
76
4.9 Plano de Recursos Humanos
O plano de recursos humanos do Projecto inclui os processos que organizam e
gerem a equipa do projecto. A equipa de Projecto consiste nas pessoas com papéis
e responsabilidades designadas para a conclusão do projecto. O tipo e o número de
membros da equipa do projecto podem mudar com frequência ao longo do projecto.
Embora os papéis e responsabilidades específicas para os membros da equipa do
projecto sejam designadas, o envolvimento de todos os membros da equipa no
planeamento do projecto e na tomada de decisões pode ser benéfico. (Guia
PMBOK, 2008).
(Colocar Imagem 9.1 do PMBOK)
4.9.1 Desenvolver o Plano de Recursos Humanos
Desenvolver o Plano de Recursos Humanos é o processo de identificar e
documentar papéis, responsabilidades, habilidades necessárias e relações
hierárquicas do projecto, e criar um plano de gerenciamento pessoal. O Plano de
Recursos Humanos é usado para determinar e identificar Recursos Humanos com
as habilidades necessárias para o êxito do projecto. O Plano de Recursos Humanos
documenta papeis e responsabilidades do projecto, Organigramas do projecto e o
Plano de Gestão do Pessoal. Também pode incluir a identificação de necessidades
de treinamento, estratégias para construção da equipa, planos para programas de
reconhecimento e recompensas, considerações sobre conformidade, questões de
segurança e o impacto do plano de Gestão de Pessoal sobre a Organização. (Guia
PMBOK, 2008).
O primeiro item do Plano de Recursos Humanos do corrente Projecto é o
Organigrama. Usou-se o Organigrama Hierárquico, pois as posições e relações são
disponibilizados sob a forma de um gráfico de cima para baixo.
77
Figura X - Organigrama da Equipa do Projecto
A partir do Organigrama é possivel obter os nomes e posições da equipa de
projectos para se definir a matriz de responsabilidades, onde para cada posição é
definida a Autoridade, Responsabilidade e Compatência. (Tabela X)
Nome Papel Autoridade Responsabilidade Competência
Edgar
Patrício
Gerente de
Projectos
Aprovar todas
as mudanças
Gerir o Projecto MBA em
Gestão de
Projectos e
experiência
em Projectos
similares.
Carlos
Martins
Analista
Sénior
Aprovar
mudançar
nos requisitos
Gerir a equipa de
Análise de
requisitos.
MBA em
ciências da
computação
Cláudio
Gomes
Administrador
de BD
Elaborar a Base
de dados
Curso
Superior de
Informática,
78
SQL Expert
Pedro
Augusto
Analista júnior Desenvolver a
análise de
reuisitos
Curso
Superior de
Informática
Leandro
Matamba
Admin. De
Aplicações
Elaborar as
especificações da
aplicação
Curso
Superior de
Informática
António
Peixoto
Programador
Sénior
Aprovar
mudanças no
código
Responsável pelo
código da
aplicação
MBA em
ciências da
computação
Carolina
Correia
Programador
júnior
Desenvolver o
código da
aplicação
Curso
Superior de
Informática
Flávia Cunha Programador
júnior
Desenvolver o
código da
aplicação
Curso
Superior de
Informática
Manuel
Sebastião
Instrutor Dar formação aos
utilizadores
12ª classe e
curso básico
de informática
Josimar João Documentador Elaborar
documentos de
Suporte
12ª classe e
curso básico
de informática
Tabela X – Matriz de Responsabilidades
4.9.2 Mobilizar a equipa de projecto
Mobilizar a equipa do projecto é o processo de confirmação da disponibilidade dos
recursos humanos e obtenção da equipa necessária para concluir as designações
do projecto. (Guia PMBOK, 2008)
79
É importante definir um calendário de recursos alocados ao projecto para não haver
conflito com outras áreas da empresa ou com recursos alocados a outros projectos.
Na tabela X é possivel observar o calendário de alocação dos membros da equipa
de projectos, de forma a garantir que esses recursos estejam disponíveis para
desenvolver as actividades do projecto.
Nome Edgar Patrício
Carlos Martins
Pedro Augusto
Cláudio Gomes
Leandro Matamba
António Peixoto
Carolina Correia
Flávia Cunha
Manuel Sebastião
Josimar João
Meses Ago-11 Set-11 Out-11 Nov-11
Tabela X – Histograma de alocação de recursos
4.9.3 Desenvolver a equipa do projecto
Desenvolver a equipa do projecto é o processo de melhoria de competências,
interacção e ambiente global da equipa para aprimorar o desempenho do projecto.
Os Gestores de Projecto devem adquirir habilidades para identificar, construir,
manter, motivar, liderar e inspirar as equipas de projecto a alcançar um alto
desempenho da equipa e cumprir os objectivos do projecto. (Guia PMBOK, 2008)
Para o projecto em questão a equipa terá uma avaliação de desempenho semanal
com o seu superior hierárquico, onde serão avaliados pelas entregas que
apresentam, desde prazo, custo e qualidade de suas entregas. Se a avaliação for
negativa, no pior cenário, o membro pode ser substituído.
Paralelamente, todas as segundas-feira, é realizada a reunião de acompanhamento
do projecto com todos os membros da equipa para que todos possam seguir a
evolução das várias fases do projecto.
80
4.9.4 Gerir a Equipa do Projecto
Gerir a equipa do projecto é o processo de acompanhar o desempenho de membros
da equipa, fornecer feedback, resolver questões e gerir mudanças para optimizar o
desempenho do projecto.
Gerir a equipa de projecto requer diversas habilidades de gestão para estimular o
trabalho em equipa e integrar os esforços dos membros da equipa para criar equipas
de alto desempenho. A gestão da equipa envolve uma combinação de habilidades,
com ênfase especial comunicação, gestão de conflitos, negociação e liderança.
(Guia PMBOK, 2008)
5. conclusões
O objetivo deste trabalho foi identificar os benefícios de um planejamento de
projectos segundo boas práticas de gerenciamento como forma de aumentar a
probabilidade de sucesso do mesmo , assim como....
81
6. POSSÍVEIS DESDOBRAMENTOS
Como resultado do seu trabalho cite e justifique alguns possíveis desdobramentos
do seu Trabalho....
82
7. REFERÊNCIAS BIBLIOGRÁFICAS
A lista abaixo corresponde SOMENTE DE EXEMPLOS de como escreveras referencias bibliográficas usadas individualmente por cada aluno, segundo padrão ABNT, aceito pelo MEC.
1. CLELAND, David I. & IRELAND, David. Project Manager’s Portable Handbook. New York:
McGraw-Hill Inc., 2000.
2. Dinsmore e outros. Como se tornar um profissional em Gerenciamento de Projetos, Editora
Quality Mark, Rio de Janeiro, 2003
3. KERZNER, Harold. Project Management: a systems approach to planning, scheduling, and
controlling. 8a edição. New York: John Willey & Sons., 2002.
4. MAXIMINIANO, A C A. Administração de Projetos, Editora Atlas, São Paulo, 2002
5. MENEZES, L C M Gestão de Projetos, Editora Atlas, São Paulo, 2001
6. PROJECT MANAGEMENT INSTITUTE. Project Management Body of Knowledge (PMBOK).
Newton Square: Project Management Institute, 2004.
8. GLOSSÁRIO
9. Apêndices
Aqui vocês podem incluir documentos, planilhas desenhos relacionados ao texto
acima.
9.1. Apêndice I – ....
Matriz de Rastreabilidade
Requisito Definição Propri
etário
Fonte Priori
dade
Versã
o
Statu
s
Data
Concl
usão
83
Emissão de
Relatórios
A aplicação
deve ser
capaz de
emitir
relatórios de
suporte
fáceis.
Equip
a de
Projec
tos e
Progra
mador
es
Termo
de
Abertu
ra
5 1.0 Activo 90
dias
User Friendly Pelo facto de
90% dos
users ter
pouco
contacto com
os
computadores
, é exigido
que a
aplicação seja
de fácil
manuseio e
seja user
friendly.
Equip
a de
Projec
tos e
Progra
mador
es
Termo
de
Abertu
ra
4 1.0 Activo 90
dias
Facilidade
para
deficientes
A aplicação
deverá ter
opções de
utilização por
parte de
deficientes
físicos, como
teclas de
atalho etc
Equip
a de
Projec
tos e
Progra
mador
es
Termo
de
Abertu
ra
2 1.0 Activo 90
dias
Globalização A aplicação Equip Termo 3 1.0 Activo 90
84
deverá dar ao
utilizador a
possibilidade
de escolher
entre 3
línguas:
Português,
Inglês e
Kimbundo.
a de
Projec
tos e
Progra
mador
es
de
Abertu
ra
dias
Web e Stand
Alone
A Aplicação
terá a
facilidade de
poder ser
utilizada via
Browser ou
Stand Alone.
Equip
a de
Projec
tos e
Progra
mador
es
Termo
de
Abertu
ra
2 1.0 Activo 90
dias
Duração da
Informação
Pela lei
angolana, a
informação
contabilística
deve poder
ser
visualizada
num período
de 5 anos. O
Software
poderá
guardar
informação
até 10 anos,
sendo que a
Equip
a de
Projec
tos e
Progra
mador
es
Termo
de
Abertu
ra
5 1.0 Activo 90
dias
85
restante
informação
será
armazenada
em Backups.
Acesso
Remoto
A empresa
Epolombo
tem fábricas e
lojas em
todas as
Províncias de
Angola, sendo
assim, o
Software será
usado em
Rede WAN
com acesso
remoto ao
servidor em
todas as
províncias.
Equip
a de
Projec
tos e
Progra
mador
es
Termo
de
Abertu
ra
3 1.0 Activo 90
dias
Segurança Por estar a
lidar com
informação
confidencial, o
software
deverá ter 1
nível de
segurança
muito alta,
tanto na
Equip
a de
Projec
tos e
Progra
mador
es
Termo
de
Abertu
ra
5 1.0 Activo 90
dias
86
informação,
como nos
níveis de
acesso que
poderão ser
atribuídos aos
Utilizadores
aos vários
módulos e
programas.
Portabilidade: Pelo facto de
o nosso país
ainda possuir
pontos sem
acesso à
Internet, a
aplicação
deverá
funcionar em
Offline, onde
o utilizador
poderá
registar
vendas,
compras,
transferências
etc sem estar
conectado à
base de
dados e
posteriorment
Equip
a de
Projec
tos e
Progra
mador
es
Termo
de
Abertu
ra
2 1.0 Activo 90
dias
87
e sincronizar
os dados.
Informação/Aj
uda:
O software
deverá ter 1
módulo de
Ajuda prático
e fácil para o
Utilizador,
com manuais,
ilustrações,
exemplos etc.
Equip
a de
Projec
tos e
Progra
mador
es
Termo
de
Abertu
ra
4 1.0 Activo 90
dias
Tabela 3 – Matriz de Rastreabilidade
88
Implementação do Software Cachi Soft
Dicionário de Dados
Código Entrega Descrição Critérios de Aceitação
1.1.1 Termo de Abertura Documento a ser elaborado pelo Gerente de Projectos e o Sponsor. Documento que irá dar poder de decisão ao Gerente de projectos. Poderá servir de contracto entre as 2 partes.
Deverá conter a descrição resumido do Projecto que se propõe a entregar e ter as aprovações do Sponsor e Gerente de Projectos.
1.1.2 Declaração de Escopo
Documento que especifica o que fazer e como deve ser
Deverá conter a descrição detalhada
89
feito. Deve servir de coluna dorsal para o Projecto e pode ser modificado consoante as necessidades.
do projecto e deverá ter as assinaturas da equipa de Gerenciamento de Projectos e do Sponsor.
1.1.3 WBS Estrutura Analítica do Projecto com o escopo do projecto. Deverá ser elaborado usando o Software WBS Chart Pro, a Fonte a usar deverá ser o Trebuchet MS tamanho 10 e deverá descrever cada produto e serviço a ser entrega ao nível do pacote de trabalho.
Deverá conter todos os produtos e serviços a serem entregues; Ter as devidas aprovações da equipa de Gerenciamento de Projectos e do Sponsor.
1.1.4 Cronograma Definição das datas previstas, marcos e actividades precedentes. Deve ser entregue o cronograma sumarizado e detalhado.
Conter as informações previstas e ser apresentada no formato indicado; Ser aprovado pela equipa de Gerenciamento de Projectos e Sponsor.
1.1.5 Orçamento Documento que especifica as recursos materiais e humanos a serem usados e os respectivos custos; Deve ser entregue o orçamento por item, orçamento por actividade, mensal e total. Tudo em planilhas do Excel.
Todos os itens de custos orçados; Custos de Aquisições acima dos 1000USD fundamentados por propostas ou cotações dos fornecedores; Ser aprovado pela equipa de Gerenciamento de Projectos e Sponsor.
1.1.7 Monitoramento e Controle
Depois de iniciado o projecto (termo de abertura e declaração de escopo) deverá haver um acompanhamento para garantir que se está a cumprir o que foi previamente acordado. Este monitoramento será feito por uma equipa especial
Que se cumpra todos os requisitos propostos para o Projecto. Orçamento, cronograma, actividades, recursos humanos e materiais, etc. Deverá ter a
90
dedicada a manter a qualidade do projecto.
aprovação da equipa de Gerenciamento de Projectos e Sponsor.
1.2.1 Requisitos de Software
Indicação dos Softwares que deverão estar presentes no computador antes de ser instalado o Software Cachi Soft.
Deverá ter Windows XP ou acima. Microsoft Office 2003 ou acima, Exchange 2003 ou acima, Microsoft SQL Server 2005 ou acima.
1.2.2 Documentação para Usuários
Primeiro esboço daquilo que será o Software, este mesmo esboço vai sofrendo alterações consoante o desenvolvimento do Software.
Deve ser de fácil leitura para qualquer utilizador que nunca tenha tido contacto com a aclicação. Deve estar no Formato Word e deve ter a fonte Times New Roman 12.
1.2.3 Requisitos de HardWare
Indicação do Hardware que o computador onde se irá instalar o Software deve ter para seu correcto funcionamento.
Deverá ter no mínimo 2Gb de Memória RAM, Processador com 2,5 Ghz. 40 GB de espaço em disco. Resolução 1280 x 820 px.
1.2.4 Implementação e Suporte
Documento que especifica como será feita a implementação do Software bem como o Suporte que será dado após o término do mesmo.
Deve ter a aprovação do Gerente de Projectos e do Sponsor. Documento Word com Fonte Times New Roman 12 .
1.2.5 Material para Treino Deverá ser já preparado o Material para Treino, para não sobrecarregar a equipa no fim do projecto. Este material será tanto para End Users como para utilizadores mais avançados (super Users e Adminitrators)
Documentos Word, Powerpoint e PDF, Word e PDF – Font Times New Roman tamanho 12. Powerpoint: Font Times New Roman tamanho 18. Deverá ter a assinatura do Gerente de projectos
91
e do Sponsor.
1.3.1 Casos de Uso Simulações das operações que serão realizadas pelo operador na aplicação. Neste diagrama serão definidos todos os tipos de utilizadores que vão interagir com a aplicação e todas as acções que os mesmos poderão realizar.
Deve ser usada a linguagem UML. Deve ter a aprovação do Gerente de projectos e do Sponsor.
1.3.2 Arquitectura de Dados
Será a primeira modelagem da estrutura de dados que vai servir de base para a elaboração da Base de dados. Nela serão definidas todas as entidades.
Deve ser usada a linguagem UML. Deve ter a aprovação do Gerente de Projectos e do Especialista em Business Analist.
1.3.3 Arquitectura de Hardware
Aqui será definido todo o Hardware que irá dar suporte a aplicação. Como é o caso dos drivers para conexões com printers, faxes, dispositivos de armazenamento, consumo de memória/processador e espaço em disco.
Deve ser apresentado num documento Word seguindo as especificações e no formato Times New Roman 12. Deve ter a aprovação do Gerente de Projectos e Business Analist.
1.3.4 Desenho da Interface Gráfica
Aqui serão apresentadas as principais entidades do modelo gráfico da aplicação. Toda a interacção gráfica do user com a aplicação. É importante ter 1 modelo gráfico que seja de fácil leitura para o user e que seja amigável.
Deverá utilizar-se a linguagem UML, posteriormente apresentar num documento Word com formato Times New Roman 12 e ter a assinatura do Gerente de projectos e Sponsor.
1.3.5 Desenho dos Objectos
Uma vez que a linguagem de programação usada será o JAVA, que é uma linguagem de programação orientada a objectos, devemos definir todos os objectos que compõem a aplicação, para podermos definir métodos, atributos e variáveis.
Deverá utilizar-se a linguagem UML. Ter a aprovação do Gerente de projectos e do Business Analist.
92
1.3.6 Desenho dos WorkFlows
Os Workflows irão definir os fluxos entre as actividades do projecto. Aqui serão definidos os comportamentos que a aplicação deverá ter para cada uma das situações vindas das operações do user. Casos de erro também serão descritos aqui.
Deverá utilizar-se a linguagem UML. Ter a aprovação do Gerente de projectos e do Business Analist.
1.3.7 Desenho de Regras As regras, juntamente com o Workflow irá definir o comportamento da aplicação ao receber inputs externos. Aqui teremos todo 1 conjunto de processos para cada acção do user. Por exemplo, o user ao pressionar o botão salvar de 1 novo cliente, todo o processo por detrás desta operação está constituído por um conjunto de regras de negócio.
Deverá utilizar-se a linguagem UML. Ter a aprovação do Gerente de projectos e do Business Analist.
1.3.8.1 Tabelas e Chaves Serão construídas as tabelas que irão compor a base de dados deste Software. Onde será armazenada toda a informação dos diferentes módulos do Software. Em paralelo será construídas também as chaves, que podem ser primárias ou estrangeiras, que vão servir para melhorar a performance nas conexões entre a aplicação e a base de dados.
A base de dados deverá ser SQL 2008. Depois de terminada será submetida a 1 especialista de Base de dados e Relatórios e deverá ter a aprovação do mesmo.
1.3.8.2 Relações As tabelas SQL deverão estar ligadas entre si para um melhor armazenamento da informação e estrutura da base de dados. Estas relações são mantidas através de Indices e Chaves.
Deverá ter a aprovação do Especialista de base de dados.
1.3.8.3 Indexação Serão constituídos índices sobre os campos de várias tabelas para garantir uma melhor performance e desempenho da aplicação sempre que necessitar fazer
Deverá ter a aprovação do Especialista de base de dados.
93
uma operação na base de dados.
1.4.1.1 Preenchimento de Tabelas Auxiliares
Existem tabelas auxiliares que devem possuir já algum conteúdo para que a aplicação possa funcionar devidamente. Como são os casos de Provincias, Municipios etc.
Conter as informações previstas.
1.4.1.2 Consultas e Scripts Existem rotinas que o Sofware necessitará de executar várias vezes. Essas rotinas serão resumidas através de scripts que podem ter vários fins: Inserir informação na Base de dados, actualizar, eliminar e obter informação.
Conter as informações previstas.
1.4.1.3 Politica de Backup Documento que irá indicar como e quando será feito o Backup da Base de dados. Deverá ter a periodicidade, o local do Backup e o tipo de Backup.
Deverá ter a aprovação do Sponsor, Gerente de Projectos e especialista de Base de dados.
1.4.2.1 Formulários/Janelas Esta é a principal parte do interface com o utilizador. São as janelas de navegação com botões, campos de texto, selecção, Radio Buttons, Check Boxes etc.
O Layout principal deverá ter a aprovação do Sponsor e Gerente de Projectos. O Fundo deverá ser cinzento e as letras a preto.
1.4.2.2 Relatórios Uma das principais funções da aplicação é a facilidade na obtenção de relatórios. Será usado o Crystal Report 2011, Reporting Services e Excel para visualização dos Reports. Grande parte dos reports irá usar os scripts e consultas do ponto 1.3.1.4.
O layout deverá ter a aprovação do Sponsor e Gerente de projectos. O Fundo será branco com letras azuis tamanho 12 e deverá ter a facilidade de exportar (Excel, pdf…)
1.4.3.1 Métodos/Funções Aqui irá todo o código de programação da aplicação, onde será definida as regras de negócio. Deverá ser desenvolvido usando a
Atender as especificações.
94
linguagem de programação JAVA.
1.4.4.1 Conexões a BD Aqui teremos Strings de Conexão a base de dados. As mesmas deverão ser inicializadas e encerradas assim que a aplicação não tiver mais necessidade de aceder a base de dados. Fruto destas conexões a aplicação poderá obter informação da base de dados para visualiza-los em relatórios ou janelas ou ainda inserir nova informação, actualizar e/ou apagar.
Atender as especificações.
1.5.1 Plano de Testes do Software
Documento que indica a importância e necessidade dos testes, bem como a sua ordem e tratamento.
Deverá ter a aprovação do Sponsor e Gerente de Projectos e deverá atender as especificações.
1.5.2 Casos de Testes do Software
Casos práticos de testes que serão feitos a aplicação para medir se a mesma é ou não robusta e se está apta para ir para produção.
Deverá ter a aprovação do Sponsor e Gerente de Projectos e deverá atender as especificações.
1.5.3 Resultados dos Testes do Software
Resultados dos testes feitos nos pontos 1.4.1 e 1.4.2, indicando se tiveram sucesso ou não.
Deverá ter a aprovação do Sponsor e Gerente de Projectos e deverá atender as especificações.
1.5.4 Aceitação do Plano de Testes
Revisão dos Planos de testes do ponto 1.4.1
Deverá ter a aprovação do Sponsor e Gerente de Projectos e deverá atender as especificações.
1.5.5 Aceitação dos Testes ao Software
Revisão dos Casos de Testes do ponto 1.4.1
Deverá ter a aprovação do Sponsor e Gerente de Projectos e deverá atender as especificações.
1.5.6 Correcção de Bugs Caso sejam detectados erros na fase de testes os mesmos
Deverá ter a aprovação do
95
deverão ser corrigidos antes da aplicação entrar no ar.
Sponsor e Gerente de Projectos e deverá atender as especificações.
1.6 Go Live Lançamento oficial do Software para ambiente de produção.
Ter a aprovação do Sponsor e Gerente de Projectos.
1.7.1 Treinamento Sessões de formação/Treinamento a todos os utilizadores, para que os mesmos entendam o funcionamento da aplicação. Este treinamento será dado tanto para End Users como para Super Users e Administradores.
Os instrutores serão sujeitos a avaliação e devem ter 1 média superior a 8.
1.7.2 Suporte É responsabilidade da empresa oferecer suporte aos utilizadores do cliente.
Ter os problemas e dúvidas resolvidas no prazo de tempo mais curto. Não deverá exceder 1 dia.
1.7.3 Termo de Encerramento
Documento que confirma o término do projecto. Se o cliente aceitou ou não o resultado final.
Atender as especificações. Deverá ter as aprovações do Gerente de projectos e do Sponsor.
1.7.4 Lições aprendidas É sempre bom colher as lições aprendidas para serem usadas em projectos futuros.
Deverá atender as especificações.
1.7.5 Desmembramento É importante usar os recursos da empresa para alocar em outros projectos que necessitem a participação desses mesmos membros.
Ter 75% dos membros livres para outros Projectos.
Tabela 4 – Dicionário de EAP
Implementação do Software Cachi Soft
Definição das Actividades
Actividade Descrição
Reunir com Sponsor para levantar o objectivo/propósito do Projecto
Reunião com a empresa EPOLOMBO para levantar as necessidades da mesma. Saber exactamente o que esperam do Software.
96
Desenvolver o Termo de Abertura
Documento a ser elaborado pelo Gerente de Projectos e o Sponsor. Documento que irá dar poder de decisão ao Gerente de projectos. Poderá servir de contracto entre as 2 partes.
Desenvolver a Declaração de Escopo
Documento que especifica o que fazer e como deve ser feito. Deve servir de coluna dorsal para o Projecto e pode ser modificado consoante as necessidades.
Desenvolver a WBS Estrutura Analítica do Projecto com o escopo do projecto. Deverá ser elaborado usando o Software WBS Chart Pro, a Fonte a usar deverá ser o Trebuchet MS tamanho 10 e deverá descrever cada produto e serviço a ser entrega ao nível do pacote de trabalho.
Elaborar Dicionário de dados
Descrição dos pacotes de dados do WBS, sua descrição e critérios de aceitação do entregável.
Desenvolver um Cronograma base com marcos apenas
Definição das datas previstas, marcos e actividades precedentes. Deve ser entregue o cronograma sumarizado e detalhado.
Desenvolver o Orçamento base
Documento que especifica as recursos materiais e humanos a serem usados e os respectivos custos; Deve ser entregue o orçamento por item, orçamento por actividade, mensal e total. Tudo em planilhas do Excel.
Monitorar e Controlar
Depois de iniciado o projecto (termo de abertura e declaração de escopo) deverá haver um acompanhamento para garantir que se está a cumprir o que foi previamente acordado. Este monitoramento será feito por uma equipa especial dedicada a manter a qualidade do projecto.
Desenvolver Plano de Requisitos de Software
Indicação dos Softwares que deverão estar presentes no computador antes de ser instalado o Software Cachi Soft.
Desenvolver a Documentação para Usuários
Primeiro esboço daquilo que será o Software, este mesmo esboço vai sofrendo alterações consoante o desenvolvimento do Software.
Desenvolver o Plano de Requisitos de HardWare
Indicação do Hardware que o computador onde se irá instalar o Software deve ter para seu correcto funcionamento.
Desenvolver o plasno de Implementação e Suporte
Documento que especifica como será feita a implementação do Software bem como o Suporte que será dado após o término do mesmo.
Desenvolver o Material para Treino
Deverá ser já preparado o Material para Treino, para não sobrecarregar a equipa no fim do projecto. Este material será tanto para End Users como para utilizadores mais avançados (super Users e Adminitrators)
Elaborar os Casos de Uso
Simulações das operações que serão realizadas pelo operador na aplicação. Neste diagrama serão definidos todos os tipos de utilizadores que vão interagir com a aplicação e todas as acções que os mesmos poderão realizar.
Desenvolver a Será a primeira modelagem da estrutura de dados que vai
97
Arquitectura de Dados
servir de base para a elaboração da Base de dados. Nela serão definidas todas as entidades.
Desenvolver a Arquitectura de Hardware
Aqui será definido todo o Hardware que irá dar suporte a aplicação. Como é o caso dos drivers para conexões com printers, faxes, dispositivos de armazenamento, consumo de memória/processador e espaço em disco.
Desenhar a Interface Gráfica
Aqui serão apresentadas as principais entidades do modelo gráfico da aplicação. Toda a interacção gráfica do user com a aplicação. É importante ter 1 modelo gráfico que seja de fácil leitura para o user e que seja amigável.
Desenhar os Objectos
Uma vez que a linguagem de programação usada será o JAVA, que é uma linguagem de programação orientada a objectos, devemos definir todos os objectos que compõem a aplicação, para podermos definir métodos, atributos e variáveis.
Desenhar os WorkFlows
Os Workflows irão definir os fluxos entre as actividades do projecto. Aqui serão definidos os comportamentos que a aplicação deverá ter para cada uma das situações vindas das operações do user. Casos de erro também serão descritos aqui.
Desenhar as Regras
As regras, juntamente com o Workflow irá definir o comportamento da aplicação ao receber inputs externos. Aqui teremos todo 1 conjunto de processos para cada acção do user. Por exemplo, o user ao pressionar o botão salvar de 1 novo cliente, todo o processo por detrás desta operação está constituído por um conjunto de regras de negócio.
Construir Tabelas e Chaves
Serão construídas as tabelas que irão compor a base de dados deste Software. Onde será armazenada toda a informação dos diferentes módulos do Software. Em paralelo será construídas também as chaves, que podem ser primárias ou estrangeiras, que vão servir para melhorar a performance nas conexões entre a aplicação e a base de dados.
Criar Relações As tabelas SQL deverão estar ligadas entre si para um melhor armazenamento da informação e estrutura da base de dados. Estas relações são mantidas através de Indices e Chaves.
Criar Indexação Serão constituídos índices sobre os campos de várias tabelas para garantir uma melhor performance e desempenho da aplicação sempre que necessitar fazer uma operação na base de dados.
Preencher as Tabelas Auxiliares
Existem tabelas auxiliares que devem possuir já algum conteúdo para que a aplicação possa funcionar devidamente. Como são os casos de Provincias, Municipios etc.
Desenvolver Consultas e Scripts
Existem rotinas que o Sofware necessitará de executar várias vezes. Essas rotinas serão resumidas através de scripts que podem ter vários fins: Inserir informação na Base de dados, actualizar, eliminar e obter informação.
Elaborar a Politica de Backup
Documento que irá indicar como e quando será feito o Backup da Base de dados. Deverá ter a periodicidade, o local do
98
Backup e o tipo de Backup.
Elaborar Formulários/Janelas
Esta é a principal parte do interface com o utilizador. São as janelas de navegação com botões, campos de texto, selecção, Radio Buttons, Check Boxes etc.
Elaborar Relatórios Uma das principais funções da aplicação é a facilidade na obtenção de relatórios. Será usado o Crystal Report 2011, Reporting Services e Excel para visualização dos Reports. Grande parte dos reports irá usar os scripts e consultas do ponto 1.3.1.4.
Elaborar Camada Intermédia
Aqui irá todo o código de programação da aplicação, onde será definida as regras de negócio. Deverá ser desenvolvido usando a linguagem de programação JAVA.
Elaborar a Camada de dados
Aqui teremos Strings de Conexão a base de dados. As mesmas deverão ser inicializadas e encerradas assim que a aplicação não tiver mais necessidade de aceder a base de dados. Fruto destas conexões a aplicação poderá obter informação da base de dados para visualiza-los em relatórios ou janelas ou ainda inserir nova informação, actualizar e/ou apagar.
Elaborar o Plano de Testes do Software
Documento que indica a importância e necessidade dos testes, bem como a sua ordem e tratamento.
Elaborar os Casos de Testes do Software
Casos práticos de testes que serão feitos a aplicação para medir se a mesma é ou não robusta e se está apta para ir para produção.
Elaborar os Resultados dos Testes do Software
Resultados dos testes feitos nos pontos 1.4.1 e 1.4.2, indicando se tiveram sucesso ou não.
Elaborar a Aceitação do Plano de Testes
Revisão dos Planos de testes do ponto 1.4.1
Elaborar a Aceitação dos Testes ao Software
Revisão dos Casos de Testes do ponto 1.4.1
Corrigir os Bugs Caso sejam detectados erros na fase de testes os mesmos deverão ser corrigidos antes da aplicação entrar no ar.
Preparar Go Live Lançamento oficial do Software para ambiente de produção.
Acompanhar o Go Live
Acompanhar o lançamento do Software, monitorando os users, a base de dados e a própria aplicação
Treinar Users Sessões de formação/Treinamento a todos os utilizadores, para que os mesmos entendam o funcionamento da aplicação. Este treinamento será dado tanto para End Users como para Super Users e Administradores.
Dar Suporte É responsabilidade da empresa oferecer suporte aos utilizadores do cliente.
Desenvolver Termo de Encerramento
Documento que confirma o término do projecto. Se o cliente aceitou ou não o resultado final.
Elaborar É sempre bom colher as lições aprendidas para serem usadas
99
documento com Lições aprendidas
em projectos futuros.
Efectuar Desmembramento
É importante usar os recursos da empresa para alocar em outros projectos que necessitem a participação desses mesmos membros.
Definir as Actividades (Gerenciamento de Tempo)
É importante definir as actividades a serem elaboradas para a realização do projecto. Aqui serão definidas e agrupadas todas as actividades necessárias para a realização do Projecto.
Sequenciar as Actividades
Depois de definir as actividades, devemos sequenciar as mesmas, ou seja, especificar quais as actividades que precedem as outras e quais as que sucedem.
Estimar Recursos das actividades
Estimar os Recursos Humanos, máquinas e materiais necessários para a conclusão de cada actividade.
Estimar duração das actividades
Estimar o tempo que deverá ser dispendido para cada actividade para que a mesma seja concluida
Desenvolvimento do Cronograma
Depois de definir as actividades, sequenciá-las, estimar os recursos e duração, devemos elaborar o cronograma com base nesses mesmos dados.
Controlar o Cronograma
Depois de elaborado o cronograma, é dever do Gestor de Projectos controlar o mesmo para saber se os prazos estão a ser cumpridos para não atrasar as actividades seguintes.
Tabela 5 – Definição das Actividades
Implementação do Software Cachi Soft
Sequenciar das Actividades
Código Activ. (Sequencia)
Actividade Descrição Dependência / Precedencia
1 Reunir com Sponsor para levantar o objectivo/propósito do Projecto
Reunião com a empresa EPOLOMBO para levantar as necessidades da mesma. Saber exactamento o que esperam do Software.
Nenhuma
2 Desenvolver o Termo de Abertura
Documento a ser elaborado pelo Gerente de Projectos e o Sponsor. Documento que irá dar poder de decisão ao Gerente de projectos. Poderá servir de contracto entre as 2 partes.
1
3 Desenvolver a Declaração de Escopo
Documento que especifica o que fazer e como deve ser feito. Deve servir de coluna dorsal para o Projecto e pode ser modificado consoante as necessidades.
2
100
4 Desenvolver a WBS Estrutura Analítica do Projecto com o escopo do projecto. Deverá ser elaborado usando o Software WBS Chart Pro, a Fonte a usar deverá ser o Trebuchet MS tamanho 10 e deverá descrever cada produto e serviço a ser entrega ao nível do pacote de trabalho.
1 e 2
5 Elaborar Dicionário de dados
Descrição dos pacotes de dados do WBS, sua descrição e critérios de aceitação do entregável.
4
6 Definir Actividades É importante definir as actividades a serem elaboradas para a realização do projecto. Aqui serão definidas e agrupadas todas as actividades necessárias para a realização do Projecto.
4 e 5
7 Sequenciar Actividades
Depois de definir as actividades, devemos sequenciar as mesmas, ou seja, especificar quais as actividades que precedem as outras e quais as que sucedem.
6
8 Estimar Recursos das Actividades
Estimar os Recursos Humanos, máquinas e materiais necessários para a conclusão de cada actividade.
7
9 Estimar Duração das Actividades
Estimar o tempo que deverá ser dispendido para cada actividade para que a mesma seja concluida
8
10 Desenvolver Cronograma
Depois de definir as actividades, sequenciá-las, estimar os recursos e duração, devemos elaborar o cronograma com base nesses mesmos dados.
9
11 Controlar Cronograma
Depois de elaborado o cronograma, é dever do Gestor de Projectos controlar o mesmo para saber se os prazos estão a ser cumpridos para não atrasar as actividades seguintes.
10
12 Desenvolver o Orçamento base
Documento que especifica as recursos materiais e humanos a serem usados e os respectivos custos; Deve ser entregue o orçamento por item, orçamento por actividade, mensal e total. Tudo em planilhas do Excel.
1
101
13 Monitorar e Controlar
Depois de iniciado o projecto (termo de abertura e declaração de escopo) deverá haver um acompanhamento para garantir que se está a cumprir o que foi previamente acordado. Este monitoramento será feito por uma equipa especial dedicada a manter a qualidade do projecto.
1
14 Desenvolver Plano de Requisitos de Software
Indicação dos Softwares que deverão estar presentes no computador antes de ser instalado o Software Cachi Soft.
1
15 Desenvolver a Documentação para Usuários
Primeiro esboço daquilo que será o Software, este mesmo esboço vai sofrendo alterações consoante o desenvolvimento do Software.
1
17 Desenvolver o Plano de Requisitos de HardWare
Indicação do Hardware que o computador onde se irá instalar o Software deve ter para seu correcto funcionamento.
1
18 Desenvolver o plano de Implementação e Suporte
Documento que especifica como será feita a implementação do Software bem como o Suporte que será dado após o término do mesmo.
1
19 Desenvolver o Material para Treino
Deverá ser já preparado o Material para Treino, para não sobrecarregar a equipa no fim do projecto. Este material será tanto para End Users como para utilizadores mais avançados (super Users e Adminitrators)
1
20 Elaborar os Casos de Uso
Simulações das operações que serão realizadas pelo operador na aplicação. Neste diagrama serão definidos todos os tipos de utilizadores que vão interagir com a aplicação e todas as acções que os mesmos poderão realizar.
14
21 Desenvolver a Arquitectura de Dados
Será a primeira modelagem da estrutura de dados que vai servir de base para a elaboração da Base de dados. Nela serão definidas todas as entidades.
14
22 Desenvolver a Arquitectura de Hardware
Aqui será definido todo o Hardware que irá dar suporte a aplicação. Como é o caso dos
14
102
drivers para conexões com printers, faxes, dispositivos de armazenamento, consumo de memória/processador e espaço em disco.
23 Desenhar a Interface Gráfica
Aqui serão apresentadas as principais entidades do modelo gráfico da aplicação. Toda a interacção gráfica do user com a aplicação. É importante ter 1 modelo gráfico que seja de fácil leitura para o user e que seja amigável.
14
24 Desenhar os Objectos
Uma vez que a linguagem de programação usada será o JAVA, que é uma linguagem de programação orientada a objectos, devemos definir todos os objectos que compõem a aplicação, para podermos definir métodos, atributos e variáveis.
20,21,22,23
25 Desenhar os WorkFlows
Os Workflows irão definir os fluxos entre as actividades do projecto. Aqui serão definidos os comportamentos que a aplicação deverá ter para cada uma das situações vindas das operações do user. Casos de erro também serão descritos aqui.
24
26 Desenhar as Regras
As regras, juntamente com o Workflow irá definir o comportamento da aplicação ao receber inputs externos. Aqui teremos todo 1 conjunto de processos para cada acção do user. Por exemplo, o user ao pressionar o botão salvar de 1 novo cliente, todo o processo por detrás desta operação está constituído por um conjunto de regras de negócio.
24
27 Construir Tabelas e Chaves
Serão construídas as tabelas que irão compor a base de dados deste Software. Onde será armazenada toda a informação dos diferentes módulos do Software. Em paralelo será construídas também as chaves,
21
103
que podem ser primárias ou estrangeiras, que vão servir para melhorar a performance nas conexões entre a aplicação e a base de dados.
28 Criar Relações As tabelas SQL deverão estar ligadas entre si para um melhor armazenamento da informação e estrutura da base de dados. Estas relações são mantidas através de Indices e Chaves.
27
29 Criar Indexação Serão constituídos índices sobre os campos de várias tabelas para garantir uma melhor performance e desempenho da aplicação sempre que necessitar fazer uma operação na base de dados.
27
30 Preencher as Tabelas Auxiliares
Existem tabelas auxiliares que devem possuir já algum conteúdo para que a aplicação possa funcionar devidamente. Como são os casos de Provincias, Municipios etc.
28,29
31 Desenvolver Consultas e Scripts
Existem rotinas que o Sofware necessitará de executar várias vezes. Essas rotinas serão resumidas através de scripts que podem ter vários fins: Inserir informação na Base de dados, actualizar, eliminar e obter informação.
30
32 Elaborar a Politica de Backup
Documento que irá indicar como e quando será feito o Backup da Base de dados. Deverá ter a periodicidade, o local do Backup e o tipo de Backup.
1
33 Elaborar Formulários/Janelas
Esta é a principal parte do interface com o utilizador. São as janelas de navegação com botões, campos de texto, selecção, Radio Buttons, Check Boxes etc.
23
34 Elaborar Relatórios Uma das principais funções da aplicação é a facilidade na obtenção de relatórios. Será usado o Crystal Report 2011, Reporting Services e Excel para visualização dos Reports. Grande
31
104
parte dos reports irá usar os scripts e consultas do ponto 1.3.1.4.
35 Elaborar Camada Intermédia
Aqui irá todo o código de programação da aplicação, onde será definida as regras de negócio. Deverá ser desenvolvido usando a linguagem de programação JAVA.
24
36 Elaborar a Camada de dados
Aqui teremos Strings de Conexão a base de dados. As mesmas deverão ser inicializadas e encerradas assim que a aplicação não tiver mais necessidade de aceder a base de dados. Fruto destas conexões a aplicação poderá obter informação da base de dados para visualiza-los em relatórios ou janelas ou ainda inserir nova informação, actualizar e/ou apagar.
27,28,29
37 Elaborar o Plano de Testes do Software
Documento que indica a importância e necessidade dos testes, bem como a sua ordem e tratamento.
35,36
38 Elaborar os Casos de Testes do Software
Casos práticos de testes que serão feitos a aplicação para medir se a mesma é ou não robusta e se está apta para ir para produção.
37
39 Elaborar os Resultados dos Testes do Software
Resultados dos testes feitos nos pontos 1.4.1 e 1.4.2, indicando se tiveram sucesso ou não.
38
40 Elaborar a Aceitação do Plano de Testes
Revisão dos Planos de testes do ponto 1.4.1
39
41 Elaborar a Aceitação dos Testes ao Software
Revisão dos Casos de Testes do ponto 1.4.1
40
42 Corrigir os Bugs Caso sejam detectados erros na fase de testes os mesmos deverão ser corrigidos antes da aplicação entrar no ar.
38,39,40,41
43 Preparar Go Live Lançamento oficial do Software para ambiente de produção.
42
44 Acompanhar o Go Live
Acompanhar o lançamento do Software, monitorando os users, a base de dados e a própria
43
105
aplicação
45 Treinar Users Sessões de formação/Treinamento a todos os utilizadores, para que os mesmos entendam o funcionamento da aplicação. Este treinamento será dado tanto para End Users como para Super Users e Administradores.
44
46 Dar Suporte É responsabilidade da empresa oferecer suporte aos utilizadores do cliente.
44,45
47 Desenvolver Termo de Encerramento
Documento que confirma o término do projecto. Se o cliente aceitou ou não o resultado final.
46
48 Elaborar documento com Lições aprendidas
É sempre bom colher as lições aprendidas para serem usadas em projectos futuros.
47
49 Efectuar Desmembramento
É importante usar os recursos da empresa para alocar em outros projectos que necessitem a participação desses mesmos membros.
48
Tabela 6 – Sequenciar as actividades
Implementação do Software Cachi Soft
Estimar Recursos das Actividades
Código Actividade Recursos
Humanos Materiais
1 Reunir com Sponsor para levantar o objectivo/propósito do Projecto
Gestor de Projecto
2 Desenvolver o Termo de Abertura
Gestor de Projecto Software: Microsoft Word
3 Desenvolver a Declaração de Escopo
Gestor de Projecto, 2 elementos seniores da Equipa de Projectos
Software: Microsoft Word
4 Desenvolver a WBS Gestor de Projecto, 4 elementos séniors da Equipa de Projectos.
Software: WBS Project Soft
5 Elaborar Dicionário de dados
Gestor de Projecto, 2 elementos séniors da Equipa de Projectos
Software: Microsoft Word
6 Definir Actividades Gestor de Projectos e 1 elemento sénior da equipa de Projectos.
Software: Microsoft Word
106
7 Sequenciar Actividades
Gestor de Projectos e 1 elemento sénior da equipa de Projectos.
Software: Microsoft Word
8 Estimar Recursos das Actividades
Gestor de Projectos e 2 elementos seniores da equipa de Projectos.
Software: Microsoft Word
9 Estimar Duração das Actividades
Gestor de Projectos e 2 elementos seniores da equipa de Projectos.
Software: Microsoft Word
10 Desenvolver Cronograma
Gestor de Projectos Software: Microsoft Project
11 Controlar Cronograma
Gestor de Projectos Software: Microsoft Project
12 Desenvolver o Orçamento base
Gestor de Projectos e 1 Contabilista Sénior
Software: Microsoft Excel e Budget TM1
13 Monitorar e Controlar
Gestor de Projectos Software: ServiceDesk 1.3
14 Desenvolver Plano de Requisitos de Software
1 Analista de Sistemas, 1 Administrador de Base de dados e 1 Programador sénior
Software: UML Developer e Microsoft Word.
15 Desenvolver a Documentação para Usuários
1 Knowledge Coordinator
Software: Microsoft Word
17 Desenvolver o Plano de Requisitos de HardWare
1 Analista de Sistemas e 1 Administrador de Sistemas
Software: Microsoft Word e WhatsUpGold.
18 Desenvolver o plano de Implementação e Suporte
Gerente de Projectos, 1 Analista de Sistemas, 1 Knowledge Coordinator
Software: Microsoft Word
19 Desenvolver o Material para Treino
1 Knowledge Coordinator
Software: Microsoft Word
20 Elaborar os Casos de Uso
1 Analista de Sistemas Software: UML Developer
21 Desenvolver a Arquitectura de Dados
1 Administrador de Base de dados
Software: UML Developer, Software: Microsoft SQL Server 2005 Enterprise Edition
22 Desenvolver a Arquitectura de Hardware
1 Administrador de Sistemas
Software: Microsoft Word e WhatsUpGold
23 Desenhar a Interface Gerente de Projectos, Software: UML Designer
107
Gráfica 1 Analista de Sistemas, 1 Administrador de Base de dados, 3 Programadores
24 Desenhar os Objectos
1 Analista de Sistemas e 3 programadores
Software: UML Designer
25 Desenhar os WorkFlows
1 Analista de Sistemas e 3 programadores
Software: UML Designer
26 Desenhar as Regras 1 Analista de Sistemas e 3 programadores
Software: UML Designer
27 Construir Tabelas e Chaves
1 Administrador de Base de dados 1 Database Developer
Software: Microsoft SQL Server 2005 Enterprise Edition, Servidor HP
28 Criar Relações 1 Administrador de Base de dados 1 Database Developer
Software: Microsoft SQL Server 2005 Enterprise Edition, Servidor HP
29 Criar Indexação 1 Administrador de Base de dados 1 Database Developer
Software: Microsoft SQL Server 2005 Enterprise Edition, Servidor HP
30 Preencher as Tabelas Auxiliares
1 Administrador de Base de dados 1 Database Developer
Software: Microsoft SQL Server 2005 Enterprise Edition, Servidor HP
31 Desenvolver Consultas e Scripts
1 Administrador de Base de dados 1 Database Developer
Software: Microsoft SQL Server 2005 Enterprise Edition, Servidor HP
32 Elaborar a Politica de Backup
1 Administrador de Base de dados 1 Database Developer
Software: Microsoft SQL Server 2005 Enterprise Edition e Microsoft Word
33 Elaborar Formulários/Janelas
5 Programadores Software: Microsoft Visual Studio 2010 C# .Net
34 Elaborar Relatórios 5 Programadores Software: Microsoft Visual Studio 2010 C# .Net
35 Elaborar Camada Intermédia
5 Programadores Software: Microsoft Visual Studio 2010 C# .Net
36 Elaborar a Camada de dados
5 Programadores Software: Microsoft Visual Studio 2010 C# .Net
37 Elaborar o Plano de Testes do Software
Gerente de Projectos, 1 Analista de Sistemas
Servidor HP de testes
38 Elaborar os Casos de Testes do Software
Gerente de Projectos, 1 Analista de Sistemas
Servidor HP de testes
39 Elaborar os Gerente de Projectos, Servidor HP de testes
108
Resultados dos Testes do Software
1 Analista de Sistemas
40 Elaborar a Aceitação do Plano de Testes
Gerente de Projectos, 1 Analista de Sistemas
Servidor HP de testes
41 Elaborar a Aceitação dos Testes ao Software
Gerente de Projectos, 1 Analista de Sistemas
Servidor HP de testes
42 Corrigir os Bugs 5 programadores Software: Microsoft Visual Studio 2010 C# .Net
43 Preparar Go Live Gerente de Projectos, 4 elementos seniores da Equipa de Projectos, 1 Knowledge Coordinator
Servidor HP Live
44 Acompanhar o Go Live
Gerente de Projectos, 4 elementos seniores da Equipa de Projectos, 1 Knowledge Coordinator, 3 programadores, 1 administrador de base de dados
Servidor HP Live
45 Treinar Users 1 Knowledge Coordinator e 2 Professores
7 computadores HP Tower
46 Dar Suporte 2 Programadores, 1 Knowledge Coordinator, 1 Administrador de Base de dados
7 computadores HP Tower
47 Desenvolver Termo de Encerramento
Gerente de Projectos Software: Microsoft Word
48 Elaborar documento com Lições aprendidas
Gerente de Projectos Software: Microsoft Word
49 Efectuar Desmembramento
Gerente de Projectos
Tabela 7 – Estimar Recursos das actividades
109
Implementação do Software Cachi Soft
Estimar Duração das actividades
Cód
Actividade Descrição Dependência Recursos Duração
1 Reunir com Sponsor para levantar o objectivo/propósito do Projecto
Reunião com a empresa EPOLOMBO para levantar as necessidades da mesma. Saber exactamento o que esperam do Software.
Nenhuma Gestor de Projecto
2 dias
2 Desenvolver o Termo de Abertura
Documento a ser elaborado pelo Gerente de Projectos e o Sponsor. Documento que irá dar poder de decisão ao Gerente de projectos. Poderá servir de contracto entre as 2 partes.
1 Gestor de Projecto Software: Microsoft Word
5 dias
3 Desenvolver a Declaração de Escopo
Documento que especifica o que fazer e como deve ser feito. Deve servir de coluna dorsal para o Projecto e pode ser modificado consoante as necessidades.
2 Gestor de Projecto, 2 elementos seniores da Equipa de Projectos Software: Microsoft Word
6 dias
4 Desenvolver a WBS
Estrutura Analítica do Projecto com o escopo do projecto. Deverá ser elaborado usando o Software WBS Chart Pro, a Fonte a usar deverá ser o Trebuchet MS tamanho 10 e deverá descrever cada produto e
1 e 2 Gestor de Projecto, 4 elementos séniors da Equipa de Projectos. Software: WBS Project Soft
6 dias
110
serviço a ser entrega ao nível do pacote de trabalho.
5 Elaborar Dicionário de dados
Descrição dos pacotes de dados do WBS, sua descrição e critérios de aceitação do entregável.
4 Gestor de Projecto, 2 elementos séniors da Equipa de Projectos Software: Microsoft Word
3 dias
6 Definir Actividades
É importante definir as actividades a serem elaboradas para a realização do projecto. Aqui serão definidas e agrupadas todas as actividades necessárias para a realização do Projecto.
4 e 5 Gestor de Projectos e 1 elemento sénior da equipa de Projectos. Software: Microsoft Word
2 dias
7 Sequenciar Actividades
Depois de definir as actividades, devemos sequenciar as mesmas, ou seja, especificar quais as actividades que precedem as outras e quais as que sucedem.
6 Gestor de Projectos e 1 elemento sénior da equipa de Projectos. Software: Microsoft Word
3 dias
8 Estimar Recursos das Actividades
Estimar os Recursos Humanos, máquinas e materiais necessários para a conclusão de cada actividade.
7 Gestor de Projectos e 2 elementos seniores da equipa de Projectos. Software: Microsoft Word
5 dias
9 Estimar Duração das Actividades
Estimar o tempo que deverá ser dispendido para cada actividade
8 Gestor de Projectos e 2 elementos seniores da
4 dias
111
para que a mesma seja concluida
equipa de Projectos. Software: Microsoft Word
10 Desenvolver Cronograma
Depois de definir as actividades, sequenciá-las, estimar os recursos e duração, devemos elaborar o cronograma com base nesses mesmos dados.
9 Gestor de Projectos Software: Microsoft Project
4 dias
11 Controlar Cronograma
Depois de elaborado o cronograma, é dever do Gestor de Projectos controlar o mesmo para saber se os prazos estão a ser cumpridos para não atrasar as actividades seguintes.
10 Gestor de Projectos Software: Microsoft Project
10 dias
12 Desenvolver o Orçamento base
Documento que especifica as recursos materiais e humanos a serem usados e os respectivos custos; Deve ser entregue o orçamento por item, orçamento por actividade, mensal e total. Tudo em planilhas do Excel.
1,2 Gestor de Projectos e 1 Contabilista Sénior Software: Microsoft Excel e Budget TM1
1 dia
13 Monitorar e Controlar
Depois de iniciado o projecto (termo de abertura e declaração de escopo) deverá haver um acompanhamento
1,2 Gestor de Projectos Software: ServiceDesk 1.3
Durante o curso do projecto.
112
para garantir que se está a cumprir o que foi previamente acordado. Este monitoramento será feito por uma equipa especial dedicada a manter a qualidade do projecto.
14 Desenvolver Plano de Requisitos de Software
Indicação dos Softwares que deverão estar presentes no computador antes de ser instalado o Software Cachi Soft.
1 1 Analista de Sistemas, 1 Administrador de Base de dados e 1 Programador sénior Software: UML Developer e Microsoft Word.
4 dias
15 Desenvolver a Documentação para Usuários
Primeiro esboço daquilo que será o Software, este mesmo esboço vai sofrendo alterações consoante o desenvolvimento do Software.
1 1 Knowledge Coordinator Software: Microsoft Word
3 dias
17 Desenvolver o Plano de Requisitos de HardWare
Indicação do Hardware que o computador onde se irá instalar o Software deve ter para seu correcto funcionamento.
1 1 Analista de Sistemas e 1 Administrador de Sistemas Software: Microsoft Word e WhatsUpGold.
2 dias
18 Desenvolver o plano de Implementação e Suporte
Documento que especifica como será feita a implementação do Software bem como o Suporte
1 Gerente de Projectos, 1 Analista de Sistemas, 1 Knowledge Coordinator
7 dias
113
que será dado após o término do mesmo.
Software: Microsoft Word
19 Desenvolver o Material para Treino
Deverá ser já preparado o Material para Treino, para não sobrecarregar a equipa no fim do projecto. Este material será tanto para End Users como para utilizadores mais avançados (super Users e Adminitrators)
1 1 Knowledge Coordinator Software: Microsoft Word
7 dias
20 Elaborar os Casos de Uso
Simulações das operações que serão realizadas pelo operador na aplicação. Neste diagrama serão definidos todos os tipos de utilizadores que vão interagir com a aplicação e todas as acções que os mesmos poderão realizar.
14 1 Analista de Sistemas Software: UML Developer
6 dias
21 Desenvolver a Arquitectura de Dados
Será a primeira modelagem da estrutura de dados que vai servir de base para a elaboração da Base de dados. Nela serão definidas todas as entidades.
14 1 Administrador de Base de dados Software: UML Developer, Software: Microsoft SQL Server 2005 Enterprise Edition
8 dias
22 Desenvolver a Arquitectura de Hardware
Aqui será definido todo o Hardware que irá dar suporte a
14 1 Administrador de Sistemas
4 dias
114
aplicação. Como é o caso dos drivers para conexões com printers, faxes, dispositivos de armazenamento, consumo de memória/processador e espaço em disco.
Software: Microsoft Word e WhatsUpGold
23 Desenhar a Interface Gráfica
Aqui serão apresentadas as principais entidades do modelo gráfico da aplicação. Toda a interacção gráfica do user com a aplicação. É importante ter 1 modelo gráfico que seja de fácil leitura para o user e que seja amigável.
14 Gerente de Projectos, 1 Analista de Sistemas, 1 Administrador de Base de dados, 3 Programadores Software: UML Designer
8 dias
24 Desenhar os Objectos
Uma vez que a linguagem de programação usada será o JAVA, que é uma linguagem de programação orientada a objectos, devemos definir todos os objectos que compõem a aplicação, para podermos definir métodos, atributos e variáveis.
20,21,22,23 1 Analista de Sistemas e 3 programadores Software: UML Designer
11 dias
25 Desenhar os WorkFlows
Os Workflows irão definir os fluxos entre as actividades do projecto. Aqui serão definidos os
24 1 Analista de Sistemas e 3 programadores Software: UML
7 dias
115
comportamentos que a aplicação deverá ter para cada uma das situações vindas das operações do user. Casos de erro também serão descritos aqui.
Designer
26 Desenhar as Regras
As regras, juntamente com o Workflow irá definir o comportamento da aplicação ao receber inputs externos. Aqui teremos todo 1 conjunto de processos para cada acção do user. Por exemplo, o user ao pressionar o botão salvar de 1 novo cliente, todo o processo por detrás desta operação está constituído por um conjunto de regras de negócio.
24 1 Analista de Sistemas e 3 programadores Software: UML Designer
7 dias
27 Construir Tabelas e Chaves
Serão construídas as tabelas que irão compor a base de dados deste Software. Onde será armazenada toda a informação dos diferentes módulos do Software. Em paralelo será construídas também as chaves, que
21 1 Administrador de Base de dados 1 Database Developer Software: Microsoft SQL Server 2005 Enterprise Edition, Servidor HP
14 dias
116
podem ser primárias ou estrangeiras, que vão servir para melhorar a performance nas conexões entre a aplicação e a base de dados.
28 Criar Relações As tabelas SQL deverão estar ligadas entre si para um melhor armazenamento da informação e estrutura da base de dados. Estas relações são mantidas através de Indices e Chaves.
27 1 Administrador de Base de dados 1 Database Developer Software: Microsoft SQL Server 2005 Enterprise Edition, Servidor HP
6 dias
29 Criar Indexação Serão constituídos índices sobre os campos de várias tabelas para garantir uma melhor performance e desempenho da aplicação sempre que necessitar fazer uma operação na base de dados.
27 1 Administrador de Base de dados 1 Database Developer Software: Microsoft SQL Server 2005 Enterprise Edition, Servidor HP
6 dias
30 Preencher as Tabelas Auxiliares
Existem tabelas auxiliares que devem possuir já algum conteúdo para que a aplicação possa funcionar devidamente. Como são os casos de Provincias, Municipios etc.
28,29 1 Administrador de Base de dados 1 Database Developer Software: Microsoft SQL Server 2005 Enterprise Edition, Servidor HP
3 dias
117
31 Desenvolver Consultas e Scripts
Existem rotinas que o Sofware necessitará de executar várias vezes. Essas rotinas serão resumidas através de scripts que podem ter vários fins: Inserir informação na Base de dados, actualizar, eliminar e obter informação.
28,29,30 1 Administrador de Base de dados 1 Database Developer Software: Microsoft SQL Server 2005 Enterprise Edition, Servidor HP
9 dias
32 Elaborar a Politica de Backup
Documento que irá indicar como e quando será feito o Backup da Base de dados. Deverá ter a periodicidade, o local do Backup e o tipo de Backup.
1 1 Administrador de Base de dados 1 Database Developer Software: Microsoft SQL Server 2005 Enterprise Edition e Microsoft Word
1 dia
33 Elaborar Formulários/Janelas
Esta é a principal parte do interface com o utilizador. São as janelas de navegação com botões, campos de texto, selecção, Radio Buttons, Check Boxes etc.
23 5 Programadores Software: Microsoft Visual Studio 2010 C# .Net
17 dias
34 Elaborar Relatórios
Uma das principais funções da aplicação é a facilidade na obtenção de relatórios. Será usado o Crystal Report 2011, Reporting
31 5 Programadores Software: Microsoft Visual Studio 2010 C# .Net
8 dias
118
Services e Excel para visualização dos Reports. Grande parte dos reports irá usar os scripts e consultas do ponto 1.3.1.4.
35 Elaborar Camada Intermédia
Aqui irá todo o código de programação da aplicação, onde será definida as regras de negócio. Deverá ser desenvolvido usando a linguagem de programação JAVA.
20,21,22,23,24,25
5 Programadores Software: Microsoft Visual Studio 2010 C# .Net
17 dias
36 Elaborar a Camada de dados
Aqui teremos Strings de Conexão a base de dados. As mesmas deverão ser inicializadas e encerradas assim que a aplicação não tiver mais necessidade de aceder a base de dados. Fruto destas conexões a aplicação poderá obter informação da base de dados para visualiza-los em relatórios ou janelas ou ainda inserir nova informação, actualizar e/ou apagar.
27,28,29 5 Programadores Software: Microsoft Visual Studio 2010 C# .Net
9 dias
37 Elaborar o Plano de Testes do Software
Documento que indica a importância e necessidade dos testes, bem como
35,36 Gerente de Projectos, 1 Analista de Sistemas Servidor HP
9 dias
119
a sua ordem e tratamento.
de testes
38 Elaborar os Casos de Testes do Software
Casos práticos de testes que serão feitos a aplicação para medir se a mesma é ou não robusta e se está apta para ir para produção.
37 Gerente de Projectos, 1 Analista de Sistemas Servidor HP de testes
4 dias
39 Elaborar os Resultados dos Testes do Software
Resultados dos testes feitos nos pontos 1.4.1 e 1.4.2, indicando se tiveram sucesso ou não.
38 Gerente de Projectos, 1 Analista de Sistemas Servidor HP de testes
3 dias
40 Elaborar a Aceitação do Plano de Testes
Revisão dos Planos de testes do ponto 1.4.1
39 Gerente de Projectos, 1 Analista de Sistemas Servidor HP de testes
2 dias
41 Elaborar a Aceitação dos Testes ao Software
Revisão dos Casos de Testes do ponto 1.4.1
40 Gerente de Projectos, 1 Analista de Sistemas Servidor HP de testes
2 dias
42 Corrigir os Bugs Caso sejam detectados erros na fase de testes os mesmos deverão ser corrigidos antes da aplicação entrar no ar.
38,39,40 5 programadores Software: Microsoft Visual Studio 2010 C# .Net
5 dias
43 Preparar Go Live
Lançamento oficial do Software para ambiente de produção.
42 Gerente de Projectos, 4 elementos seniores da Equipa de Projectos, 1 Knowledge Coordinator Servidor HP Live
1 dia
44 Acompanhar o Go Live
Acompanhar o lançamento do
43 Gerente de Projectos, 4
3 dias
120
Software, monitorando os users, a base de dados e a própria aplicação
elementos seniores da Equipa de Projectos, 1 Knowledge Coordinator, 3 programadores, 1 administrador de base de dados Servidor HP Live
45 Treinar Users Sessões de formação/Treinamento a todos os utilizadores, para que os mesmos entendam o funcionamento da aplicação. Este treinamento será dado tanto para End Users como para Super Users e Administradores.
44 1 Knowledge Coordinator e 2 Professores 7 computadores HP Tower
8 dias
46 Dar Suporte É responsabilidade da empresa oferecer suporte aos utilizadores do cliente.
44,45 2 Programadores, 1 Knowledge Coordinator, 1 Administrador de Base de dados 7 computadores HP Tower
8 dias
47 Desenvolver Termo de Encerramento
Documento que confirma o término do projecto. Se o cliente aceitou ou não o resultado final.
46 Gerente de Projectos Software: Microsoft Word
1 dia
48 Elaborar documento com
É sempre bom colher as lições
47 Gerente de Projectos
1 dia
121
Lições aprendidas
aprendidas para serem usadas em projectos futuros.
Software: Microsoft Word
49 Efectuar Desmembramento
É importante usar os recursos da empresa para alocar em outros projectos que necessitem a participação desses mesmos membros.
48 Gerente de Projectos
1 dia
Tabela 8 – Estimativa das durações das actividades
RISCOS
1 Ultrapassar o Orçamento previsto
2 Atrasos nas actividades do cronograma
3 Quebra de discos no Servidor de Aplicações
4 Quebra de discos no Servidor de Base de dados
5 Base de dados corrupta devido a falhas de rede ou energia
6 Perda dos ficheiros com código (programação)
7 Má percepção do resultado do projecto por parte do cliente
8 Falta de “know how” por parte dos utilizadores finais (pouca aptidão em informática)
9 Falta de informação para preencher as tabelas
10 Base de dados mal desenhada
11 Bugs no Software
12 Mudanças no escopo solicitadas pelo cliente
13 Ultrapassar o espaço em disco para armazenamento de dados
14 Cortes eléctricos que afectam os computadores/servidores
15 Falhas na rede informática
16 Escassez de endereços IP
17 Lentidão nos sites mais remotos (de províncias menos desenvolvidas)
18 Falha na conexão dos sites com a central
19 Não aceitação do produto final por parte do cliente
20 Invasão por parte de Hackers
21 Servidores inadequados
22 Incompatibilidade de Software
23 Incompatibilidade de hardware
24 Uso da aplicação por parte de portadores de deficiências
25 Utilizadores que não falam português
26 Utilizadores não sabem como utilizar certas funcionalidades do Programa
27 Dificuldade em obtenção da informação/dados por parte dos utilizadores
28 Falta de segurança em certas filiais espalhadas pelo país
122
29 Dificuldade de acesso a certos sites remotos
No. Risco
Evento de
Risco
Categoria
Probabilidade do
Risco
Impacto do Risco
Severidade (P x I)
Prioridade
Resposta ao Risco
Descrição
da resposta
Urgência de resposta
Responsável
(dono) pelo Risco
Data limite
Descrição do gatilho
do risco (Risk
Trigger)
[Escopo]
[Tempo]
[Custo]
[Qualidade
]
1 Ultrapassar o Orçamento previsto
INTERNO
0,4 0,2
0,2
0,8
0,1 0,32
3 ACEITAR
Ver Documento de Riscos
2 dias
GP - Edgar Patricio
10-12-2011
Atingir 90% do Orçamento antes do término
2 Atrasos nas actividades do cronograma
GESTÃO DE PROJECTO
0,8 0,2
0,8
0,2
0,2 0,64
3 ACEITAR
Ver Documento de Riscos
1 dia
GP - Edgar Patricio
10-12-2011
Relação Trabalho Feito/Tempo abaixo dos 80%
3 Quebra de discos no Servidor de Aplicações
TÉCNICO
0,1 0,2
0,4
0,4
0,2 0,04
1 TRANSFERIR
Ver Documento de Riscos
1 dia
IT Manager - Antonio Peixoto
13-12-2011
Disco Cheio, Relatório de Log de Erros
4 Quebra de discos no
TÉCNICO
0,1 0,2
0,4
0,4
0,2 0,04
2 TRANSFERIR
Ver Docume
1 dia
IT Manager -
10-1
Disco Cheio, Relatório de
123
Servidor de Base de dados
nto de Riscos
Antonio Peixoto
2-2011
Log de Erros
5 Base de dados corrupta devido a falhas de rede ou energia
TÉCNICO
0,2 0,2
0,2
0,2
0,2 0,04
2 TRANSFERIR
Ver Documento de Riscos
1 dia
Database Admin - Carlos Martins
10-12-2011
Oscilações frequentes na rede/energia e lentidão nas operações de acesso a Base de dados
6 Perda dos ficheiros com código (programação)
TÉCNICO
0,2 0,4
0,4
0,2
0,4 0,08
2 MITIGAR
Ver Documento de Riscos
1 dia
IT Manager - Antonio Peixoto
11-12-2011
Não tem Trigger
7 Má percepção do resultado do projecto por parte do cliente
EXTERNO
0,4 0,8
0,4
0,4
0,4 0,32
3 MITIGAR
Ver Documento de Riscos
3 dias
GP - Edgar Patricio
14-12-2011
Feedback do Cliente nas Reuniões de andamento do projecto.
8 Falta de “know how” por parte dos utilizad
EXTERNO
0,8 0,8
0,4
0,4
0,4 0,64
3 MITIGAR
Ver Documento de Ris
5 dias
Coordenadora de Formações
11-12-2
Resultados dos exames feitos na formaç
124
ores finais (pouca aptidão em informática)
cos - Fávia Cunha
011
ão com os End Users
9 Falta de informação para preencher as tabelas
EXTERNO
0,2 0,4
0,4
0,1
0,8 0,16
1 MITIGAR
Ver Documento de Riscos
3 dias
Database Admin - Carlos Martins
13-12-2011
Nível de percepção do Cliente nas reuniões de andamento do projecto.
10
Base de dados mal desenhada
INTERNO
0,1 0,8
0,8
0,1
0,8 0,08
2 MITIGAR
Ver Documento de Riscos
4 dias
Database Admin - Carlos Martins
10-12-2011
Mau funcionamendo da Base de dados, relações entre tabelas mal feito, Chaves e Indexes mal criados e dificuldade na optimização dos dados;
11
Bugs no Software
INTERNO
0,4 0,1
0,4
0,1
0,8 0,32
3 MITIGAR
Ver Documento
6 dias
Database Admin -
12-12
Plano de Testes do Softwa
125
de Riscos
Carlos Martins
-2011
re - Nível de Aceitação deve ser maior do que 80%
12
Mudanças no escopo solicitadas pelo cliente
EXTERNO
0,4
0,8
0,4
0,4 0,2
0,32
3 ACEITAR
Ver Documento de Riscos
3 dias
GP - Edgar Patricio
12-12-2011
Reuniões de andamento do projecto - Feedback do Cliente.
13
Ultrapassar o espaço em disco para armazenamento de dados
TÉCNICO
0,1
0,1
0,1
0,4 0,2
0,04
1 MITIGAR
Ver Documento de Riscos
1 dia
Database Admin - Carlos Martins
11-12-2011
Uso de 80% do espaço em Disco
14
Cortes eléctricos que afectam os computadores/servidores
TÉCNICO
0,4
0,1
0,1
0,4 0,4
0,16
2 TRANSFERIR
Ver Documento de Riscos
1 dia
IT Manager - Antonio Peixoto
11-12-2011
Medidor de tensão. Oscilações superiores a 70%
15
Falhas na rede informática
TÉCNICO
0,4
0,1
0,2
0,4 0,4
0,16
2 TRANSFERIR
Ver Documento de Riscos
6 dias
IT Manager - Antonio Peixoto
12-12-20
Plano de Testes aos Routers, Switches,
126
11
Servidores etc. Nível de aceitação infeiror a 80%
16
Escassez de endereços IP
TÉCNICO
0,2
0,1
0,2
0,2 0,4
0,08
1 TRANSFERIR
Ver Documento de Riscos
1 dia
IT Manager - Antonio Peixoto
15-12-2011
Número de endereços IP superior a 60% da capacidade total da Rede.
17
Lentidão nos sites mais remotos (de províncias menos desenvolvidas)
TÉCNICO
0,8
0,1
0,1
0,2 0,8
0,64
1 TRANSFERIR
Ver Documento de Riscos
1 dia
IT Manager - Antonio Peixoto
10-12-2011
Teste de Conexão através de Pings. O Tempo superior a 1000ms.
18
Falha na conexão dos sites com a central
TÉCNICO
0,8
0,1
0,2
0,2 0,8
0,64
1 TRANSFERIR
Ver Documento de Riscos
1 dia
IT Manager - Antonio Peixoto
10-12-2011
Teste de Conexão através de Pings. O Tempo superior a 1000ms.
127
19
Não aceitação do produto final por parte do cliente
EXTERNO
0,1
0,8
0,4
0,4 0,2
0,08
3 MITIGAR
Ver Documento de Riscos
1 dia
GP - Edgar Patricio
11-12-2011
Feedback do Cliente nas Reuniões de andamento do projecto.
20
Invasão por parte de Hackers
TÉCNICO
0,2
0,1
0,2
0,8 0,8
0,16
2 MITIGAR
Ver Documento de Riscos
1 dia
IT Manager - Antonio Peixoto
13-12-2011
Testes de Segurança. Fracos resultados
21
Servidores inadequados
TÉCNICO
0,1
0,1
0,1
0,4 0,4
0,04
1 MITIGAR
Ver Documento de Riscos
1 dia
IT Manager - Antonio Peixoto
14-12-2011
Plano de Requisitos do Sistema - Servidores com especificações inferiores ao do plano
22
Incompatibilidade de Software
TÉCNICO
0,2
0,1
0,1
0,1 0,4
0,02
1 MITIGAR
Ver Documento de Riscos
1 dia
IT Manager - Antonio Peixoto
11-12-2011
Plano de Requisitos do Sistema - Softwares inferiores ou incompactiveis
128
com o do plano
23
Incompatibilidade de hardware
TÉCNICO
0,2
0,1
0,1
0,2 0,4
0,04
1 MITIGAR
Ver Documento de Riscos
1 dia
IT Manager - Antonio Peixoto
10-12-2011
Plano de Requisitos do Sistema - Hardware inferior ou incompactivel com o do plano.
24
Uso da aplicação por parte de portadores de deficiências
EXTERNO
0,2
0,1
0,1
0,1 0,1
0,02
1 MITIGAR
Ver Documento de Riscos
2 dia
Database Admin - Carlos Martins
11-12-2011
Lista de Utilizadores - Secção portador de Deficiências com número superior a 0
25
Utilizadores que não falam português
EXTERNO
0,4
0,2
0,1
0,1 0,1
0,08
1 MITIGAR
Ver Documento de Riscos
2 dias
Database Admin - Carlos Martins
11-12-2011
Lista de Utilizadores - Secção Língua. Diferente de Português
26
Utilizadores não sabem como utilizar
EXTERNO
0,4
0,2
0,2
0,2 0,2
0,08
2 MITIGAR
Ver Documento de
3 dias
Database Admin - Carl
14-12-
Resultados dos exames feitos na
129
certas funcionalidades do Programa
Riscos
os Martins
2011
formação com os End Users
27
Dificuldade em obtenção da informação/dados por parte dos utilizadores
EXTERNO
0,4
0,4
0,2
0,1 0,4
0,16
2 MITIGAR
Ver Documento de Riscos
3 dias
Database Admin - Carlos Martins
14-12-2011
Resultados dos exames feitos na formação com os End Users
28
Falta de segurança em certas filiais espalhadas pelo país
TÉCNICO
0,8
0,1
0,1
0,8 0,1
0,64
2 TRANSFERIR
Ver Documento de Riscos
6 dias
GP - Edgar Patricio
12-12-2011
Testes de Segurança. Fracos resultados
29
Dificuldade de acesso a certos sites remotos
TÉCNICO
0,8
0,1
0,2
0,4
0,05
0,32
1 TRANSFERIR
Ver Documento de Riscos
7 dias
GP - Edgar Patricio
15-12-2011
Mapa de Angola - Vias Rodoviárias em construção/Reparação ou em más condições
Tabela CCC – Registo dos Riscos (Análise Qualitativa e Quantitativa)
130
Num.
Risco
RISCO Estratégia Resposta ao Risco
1 Ultrapassar o Orçamento previsto
ACEITAR Utilizar a Contingência de Custo. Será reservado 1 contingência de custo no valor de 20% do total do orçamento. Este valor só será usado com a devida autorização do Director Financeiro e GP, com a respectiva justificação. Serão feitas revisões periódicas ao Orçamento vs Actual.
2 Atrasos nas actividades do cronograma
ACEITAR Alocação de mais pessoas nas actividades sem folga. Utilizar para tal o plano de contingência de tempo. Essa contingência deverá ser usada para casos em que haja a necessidade de se alocar mais técnicos para aumento de produtividade. Deverá também ter a aprovação do GP e Director Geral.
3 Quebra de discos no Servidor de Aplicações
TRANSFERIR Este risco será transferido para a empresa que dá suporte informático a empresa EPOLOMBO.
4 Quebra de discos no Servidor de Base de dados
TRANSFERIR Este risco será transferido para a empresa que dá suporte informático a empresa EPOLOMBO.
5 Base de dados corrupta devido a falhas de rede ou energia
TRANSFERIR Este risco será transferido para a empresa que dá suporte informático a empresa EPOLOMBO.
6 Perda dos ficheiros com código (programação)
MITIGAR Cada programador tem o Backup de seus ficheiros. Há ainda 1 pasta partilhada onde todos os programadores poderão colocar os ficheiros com código. Dessa pasta
131
partilhada será feito 1 backup diário para 1 servidor localizado em São Paulo (Brasil). Em caso de perda de ficheiros iremos primeiro aceder a pasta partilhada e caso a pasta também tenha problemas iremos aceder a pasta no exterior do país.
7 Má percepção do resultado do projecto por parte do cliente
MITIGAR Durante a execução do projecto haverá uma reunião semanal todas as segundas para que o cliente possa acompanhar a evolução do mesmo, garantindo assim que não haja má interpretação no final. Caso o cliente não aceite o produto final temos as evidências dessas reuniões com a aprovação do cliente.
8 Falta de “know how” por parte dos utilizadores finais (pouca aptidão em informática)
MITIGAR Foi feita uma sondagem de todos os utilizadores que terão acesso a aplicação. Depois dessa sondagem serão feitos exames práticos para medir a capacidade dos utilizadores. Mediante os resultados obtidos será dada a formação separando os grupos por grau de conhecimento.
9 Falta de informação para preencher as tabelas
MITIGAR No acordo assinado entre as 2 empresas, a empresa EPOLOMBO garantiu que iria dar toda a informação necessária para a elaboração do projecto, está nas premissas do projecto. No entanto existem reuniões quinzenais entre a área administrativa da empresa EPOLOMBO e os
132
programadores da nossa empresa para garantir que esta premissa está a ser cumprida. Em caso de falha será enviado 1 documento para a administração da empresa reportando a falta de colaboração.
10 Base de dados mal desenhada
MITIGAR Temos uma equipa de programadores, analistas de sistemas e administradores de base de dados a trabalhar connosco. Caso se note algum problema ligado a base de dados, haverá 1 brainstorming entre essa equipa para resolver o mesmo, sendo que na pior das hipóteses teremos que refazer a mesma.
11 Bugs no Software MITIGAR A actividade 1.5.6 da nossa WBS prevê a correcção de Bugs depois de serem efectuados os testes à aplicação. A equipa de programadores deverá estar apta para refazer o código de forma a superar o BUG.
12 Mudanças no escopo solicitadas pelo cliente
ACEITAR O cliente poderá sempre pedir mudanças no escopo do projecto. Para toda e qualquer mudança feita no escopo deverá ter assinatura do Sponsor, bem como do GP e deverá ser revista pelo Director Financeiro para alocação de novos custos caso seja necessário.
13 Ultrapassar o espaço em disco para armazenamento de dados
MITIGAR A actividade 1.2.3 refere-se aos Requisitos de Hardware. Nesses requisitos serão descritas as capacidades que o
133
hardware deve possuir. Esse documento será assinado pelo Sponsor. Toda e qualquer compra fora desse escopo será da total responsabilidade do cliente.
14 Cortes eléctricos que afectam os computadores/servidores
TRANSFERIR Este risco será transferido para a empresa responsável pela manutenção eléctrica da empresa EPOLOMBO.
15 Falhas na rede informática TRANSFERIR Este risco será transferido para a empresa que dá suporte informático a empresa EPOLOMBO.
16 Escassez de endereços IP TRANSFERIR Este risco será transferido para a empresa que dá suporte informático a empresa EPOLOMBO.
17 Lentidão nos sites mais remotos (de províncias menos desenvolvidas)
TRANSFERIR Este risco será transferido para a empresa que dá suporte informático a empresa EPOLOMBO.
18 Falha na conexão dos sites com a central
TRANSFERIR Este risco será transferido para a empresa que dá suporte informático a empresa EPOLOMBO.
19 Não aceitação do produto final por parte do cliente
MITIGAR Durante a execução do projecto haverá uma reunião semanal todas as segundas para que o cliente possa acompanhar a evolução do mesmo, garantindo assim que não haja má interpretação no final. Caso o cliente não aceite o produto final temos as evidências dessas reuniões com a aprovação do cliente.
20 Invasão por parte de Hackers
MITIGAR A nossa aplicação usa o protocolo SSL para protecção das páginas WEB, que é onde reside a maior probabilidade de ataques externos. Para além disso temos 1
134
algoritmo de autenticação muito seguro. Se mesmo assim ocorrer uma invasão externa temos Backup da base de dados e de todos os ficheiros bem como o log de todos os acessos ao servidor.
21 Servidores inadequados MITIGAR A actividade 1.2.3 refere-se aos Requisitos de Hardware. Nesses requisitos serão descritas as capacidades que o hardware deve possuir. Esse documento será assinado pelo Sponsor. Toda e qualquer compra fora desse escopo será da total responsabilidade do cliente.
22 Incompatibilidade de Software
MITIGAR A actividade 1.2.4 refere-se aos Requisitos de Software. Nesses requisitos serão descritas as capacidades que o hardware deve possuir. Esse documento será assinado pelo Sponsor. Toda e qualquer compra fora desse escopo será da total responsabilidade do cliente.
23 Incompatibilidade de hardware
MITIGAR A actividade 1.2.3 refere-se aos Requisitos de Hardware. Nesses requisitos serão descritas as capacidades que o hardware deve possuir. Esse documento será assinado pelo Sponsor. Toda e qualquer compra fora desse escopo será da total responsabilidade do cliente.
24 Uso da aplicação por parte de portadores de deficiências
MITIGAR Um dos requisitos do projecto foi que a aplicação estivesse preparada para a
135
utilização por parte de portadores de deficiência. A mesma possui teclas de atalho, reprodutor de sons, telas especiais e elucidativas. Se algum portador de deficiências utilizar a aplicação bastará activar estas funcionalidades.
25 Utilizadores que não falam português
MITIGAR Outro requisito do projecto foi que a aplicação suportasse 3 línguas: Português,inglês e Kimbundo. Qualquer língua fora destas 3 não é suportada pela aplicação, como descrita nos requisitos.
26 Utilizadores não sabem como utilizar certas funcionalidades do Programa
MITIGAR O ponto 1.2.5 da nossa WBS prevê a elaboração de material para treino que será usado pelos utilizadores. O ponto 1.7.1 prevê a formação aos utilizadores para que os mesmos conheçam as funcionalidades. Por fim o ponto 1.7.2 prevê Suporte aos utilizadores para dissipar todas as dúvidas referentes ao Software.
27 Dificuldade em obtenção da informação/dados por parte dos utilizadores
MITIGAR Os pontos 1.4.1.2 e 1.4.2.2 prevê a elaboração de relatórios e consultas feitas com o cliente, para obtenção das necessidades em termos de informação. Caso sejam necessários novos relatórios então será enviada a solicitação para a equipa de base de dados e Programação para desenvolverem esse relatório.
28 Falta de segurança em certas filiais espalhadas
TRANSFERIR Esta responsabilidade foi transferida para a
136
pelo país empresa de segurança do sponsor.
29 Dificuldade de acesso a certas filiais remotas
TRANSFERIR Foi dispensado 1 helicóptero para aceder as filiais mais remotas.
137