análise e desenvolvimento de sistema de gestão de...

Faculdade de Engenharia da Universidade do Porto

Análise e Desenvolvimento de Sistema de Gestão de Projectos de IDI

Alexandre Ferreira Gomes

VERSÃO PROVISÓRIA

Preparação da Dissertação realizada no âmbito do Mestrado Integrado em Engenharia Electrotécnica e de Computadores

Major Automação

Orientador: Prof. Dr. José António Faria Co-Orientador: Prof. Gil Gonçalves

15 Fevereiro de 2011

ii

© Alexandre Ferreira Gomes, 2011

iii

Resumo

Nesta dissertação procura-se explorar metodologias de gestão de projectos bem como metodologias de análise para o mesmo. Em concreto, apresenta-se uma abordagem ao problema de gestão de equipas de trabalho em que existe carência na organização e inconsistência de métodos. A modelação/correcção destes problemas será efectuada através da utilização de diversas metodologias, presentes no capítulo dois deste documento (estado da arte), assim como através do uso do conhecimento com vista ao desenvolvimento de possíveis técnicas novas/inovadoras. Dada a natureza do domínio, projecto PitVant, foi necessário realizar algumas tarefas de pré-processamento, como é o caso do modelo AS-IS do projecto. Posteriormente, será desenvolvido o modelo TO-BE relativo a este domínio, com vista à implementação de melhorias. Além deste último modelo, pretende-se também a elaboração de uma interface própria para cada processo do projecto. Esta interface deve ser a mais dedicada possível ao trabalho dos elementos da equipa, de forma a ajudá-los no seu dia-a-dia. Existirão três interfaces, pois trata-se de três processos distintos em análise (missão, desenvolvimento de produto e gestão global do projecto).

v

Abstract

This dissertation attempts to explore methodologies for project management as well as methods of analysis for the same. Specifically, it presents an approach to the problem of managing work teams in which there is a lack of inconsistency in the organization and working methods. The shaping / correction of these problems will be performed using various methodologies, presented in Chapter Two of this document (state of the art), as well as through the use of knowledge in order to develop possible new techniques / innovation. Given the nature of the field, PitVant project, it was necessary to take care of some pre-processing such as the AS-IS model of the project. The model TO-BE for this area will be developed later as a form of improvement. Besides this latest model, the aim is also developing a unique interface to each process of the project; this interface should be as dedicated as possible to the work of the team, to help them in their day-to-day. There are going to be three interfaces, because these are three separate cases in the analysis (mission, product development and overall project management).

vii

“a project is not a repetitive job, planned and carried out according to certain specifications, and cost objectives,

investments and predefined terms. It also defines a project as a work of considerable complexity and volume, to be held with the participation of various departments of a company

and possibly with the involvement of third parties.”

Brown Boveri

ix

Índice Resumo ............................................................................................ iii

Abstract ............................................................................................. v

Lista de figuras .................................................................................... x

Lista de tabelas .................................................................................. xii

Abreviaturas e Símbolos ....................................................................... xiii

Capítulo 1 .......................................................................................... 1

Introdução ........................................................................................................ 1

1.1 Motivação da dissertação ....................................................................... 1

1.2 Objectivo da dissertação ....................................................................... 2

1.3 Enquadramento ................................................................................... 2

1.4 Resultados esperados ............................................................................ 3

1.5 Metodologia utilizada ........................................................................... 4

Capítulo 2 .......................................................................................... 6

Estado da Arte ................................................................................................... 6

Metodologias de gestão de projectos, análise de projectos e actividades IDI ........................ 6

2.1 Estado da Arte .................................................................................... 6

2.2 Metodologias de gestão de projectos: Pesquisa ............................................ 7

2.3 Modelos para projectos: Pesquisa ........................................................... 18

2.4 Softwares de gestão/ modelação de projectos: Pesquisa .............................. 24

2.5 Ferramentas de suporte ...................................................................... 28

2.6 Conclusões....................................................................................... 30

Referências ....................................................................................... 31

x

Lista de figuras

Figura 2.1 - Ciclo da metodologia BPM. [5] ............................................................... 8

Figura 2.2 - Ciclo da metodologia ACM. ................................................................... 9

Figura 2.3 - Ciclo da metodologia PMBOK. [7] .......................................................... 10

Figura 2.4 – Ciclo da metodologia Scrum. [9] ........................................................... 11

Figura 2.5 – Exemplo de uma página com informação total do projecto.[10] .................... 12

Figura 2.6 - Metodologia XP. [13] ......................................................................... 13

Figura 2.7 - Metodologia PDCA. [15] ..................................................................... 14

Figura 2.8 - Actividades do manual de IDI. [16] ........................................................ 15

Figura 2.9 – Metodologia DECLARE. ....................................................................... 16

Figura 2.10 – Ilustracção do modelo Swimlane. [18] .................................................. 19

Figura 2.11 – Ilustração do modelo tipo matriz. ....................................................... 20

Figura 2.12 - Ilustração do modelo Pert/CPM. [19] .................................................... 21

Figura 2.13 - Ilustração do diagrama de Gantt. [21] .................................................. 22

Figura 2.14 - Ilustração do diagrama WBS. [23] ........................................................ 23

Figura 2.15 - Ilustração do diagrama SBS. ............................................................... 23

Figura 2.16 - Ilustração do Fluxograma e símbolos. [24] ............................................. 24

Figura 2.17 - Ilustração da interface do MS Project. [25] ............................................ 25

Figura 2.18 - Ilustração da interface do Redmine. [26] ............................................... 26

Figura 2.19 - Ilustração da interface do Microsoft Visio. [29] ....................................... 27

xi

Figura 2.20 - Ilustração da interface do Bizagi. [30] .................................................. 28

Figura 2.21 - Ilustração da ferramenta TO-DO list. .................................................... 29

Figura 2.22 - Ilustração da ferramenta do Checklist. [31]............................................ 29

xii

Lista de tabelas

Tabela 1 – Tabela comparativa das metodologias. .................................................... 17

xiii

Abreviaturas e Símbolos

ACM Adaptive Case Management AS-IS Modelo/ estado actual do programa CAD Computer Aided Drafting CPM Critical Path Method BPM Business Process Management BPMN Business Process Modeling Notation FEUP Faculdade de Engenharia da Universidade do Porto IDI Investigação, Desenvolvimento e Inovação INNESC Instituto de Engenharia de Sistemas e Computadores MS Project Microsoft Project OPPM One page project manager PDCA Plan, Do, Check and Act PERT Program Evaluation and Review Technique PitVant Investigação e Tecnologia em Veículos Aéreos Não Tripulados PMBOK Project Management Body of Knowledge PMI Project Management Institute TO-BE Modelo/ estado futuro do programa TSP Team Software Process UML Unified Modeling Language XP Extreme Programming WBS Work Breakdown Structure WFMS Workflow Management System YAWL Yet Another Workflow Language

1

Capítulo 1

Introdução

1.1 Motivação da dissertação A Gestão de Projectos envolve muitos profissionais, com diversas funções, em

organizações de qualquer sector de actividade. As empresas mais competitivas reconhecem na Gestão de Projectos a metodologia adequada à gestão da mudança e, mais concretamente, à implementação de estratégias que assegurem inovação permanente, flexibilidade, agilidade, comunicação, ou seja, os factores reconhecidamente determinantes da competitividade.

A gestão dos projectos, IDI no caso em estudo, caracteriza-se pelo facto do planeamento estar sujeito a alterações frequentes e por haver uma forte integração dos processos e tarefas com a base de conhecimento.

Não existem dois projectos iguais, pois existe uma grande panóplia de características que diferem de projecto para projecto. Estas características podem ser: tamanho, complexidades, tipos de actividade, diferentes grupos de pessoas, etc. Todas estas características levam a que o processo de gestão seja adaptável e variável para colmatar as necessidades de cada um deles. Surge então a necessidade de garantir que os projectos tenham uma gestão eficaz e bem coordenada com o intuito de garantir que:

Existe comunicação dentro das equipas; Existe homogeneidade de documentos e formas de interagir entre elementos

pertencentes a um projecto; As pessoas cumprem com as deadlines e milestones; Todos têm acesso à informação necessária para desenvolvimento das tarefas

alocadas; As ferramentas a utilizar sejam fáceis, leves, organizadas e equilibradas; Existe gestão temporal exacta; Existe um planeamento; etc.

Os pontos acima citados são falhas em muitos projectos e colmatados evitam alguns problemas.

2 Introdução

Esta dissertação será baseada no estudo do Projecto PitVant - Investigação e Tecnologia em Veículos Aéreos Não Tripulados, assim servindo de caso de estudo.

Este projecto é de grande dimensão e complexidade, envolvendo muitos indivíduos, muitas tarefas, missões, etc. Desta forma será efectuado o AS-IS do projecto, através do qual serão desenvolvidas melhorias, implementado métodos de gestão variados. [1]

1.2 Objectivo da dissertação

Desenvolver o sistema de gestão / informação de suporte à Equipa PitVant o que

inclui: A análise de requisitos ao nível da:

Gestão do trabalho/actividade; Gestão da informação; Gestão da colaboração.

Especificação das interfaces; O teste/utilização do sistema e a sua avaliação; Desenvolvimento de metodologias de suporte aos processos de gestão de

inovação; Elaboração de procedimentos relativos à Gestão de projectos:

Organização do dossier dos projectos; Planeamento e controlo da actividade; Comunicação interna e relatórios; Prestação de contas; Gestão do risco; Regras para a especificação, análise (arquitectura), teste, etc.

1.3 Enquadramento O projecto será desenvolvido nas instalações da Faculdade de Engenharia da Universidade

do Porto. O caso de estudo, tal como referido anteriormente, é o Projecto PitVant. Este projecto

baseia-se em Investigação e Tecnologia de Veículos Aéreos Não Tripulados em que participa a Academia da Força Aérea Portuguesa e a Faculdade de Engenharia da Universidade do Porto. Esta aliança, e consequente desenvolvimento, iniciou-se nos princípios do ano de 2009, tendo como duração definida de 7 anos.

A investigação e desenvolvimento são realizados pelas duas instituições de forma conjunta, implicando um contacto muito próximo entre elas. Todas as missões/ tarefas são do conhecimento de ambas e realizadas envolvendo o conhecimento das equipas de cada parte.

A FEUP participa neste projecto com a envolvência de 9 elementos Todo o estudo realizado para este projecto será com apoio desta equipa, assim como

também, investigação e pesquisa. Já foi possível apurar alguns problemas relativos à equipa, como por exemplo:

3

Gestão de documentação; Planeamentos; Actualização da To-Do list; Repositório actualizado e organizado; Existência de templates para elaboração de documentos específicos; Notificações de aviso; Gestão de presenças.

Para além dos problemas já detectados, e após estudo do projecto, foi possível detectar três processos fundamentais:

Processo missão: este processo pode ser visto segundo duas perspectivas pois podemos definir uma parte de índole constante e outra variável. Ou seja, podemos ver este como um processo constante/repetível quando definimos objectivos e planeamos a missão mas podemos também observar a existências uma parte variável/irrepetível como na parte da execução da mesma. Por exemplo, o local de execução de uma missão variam, logo será necessário saber onde se colocar o avião, saber se as condições atmosféricas são as ideias para fazer os testes da missão. Existe muitos passos que não podem se colocados num template pois estes dependem da avaliação dos responsáveis, entrando aqui o conhecimento dos intervenientes. Neste último ponto evidencia-se a utilização de metodologias ágeis;

Processo desenvolvimento de produto: este processo segue 4 questões fundamentais: “what” (ofertas) - o que a organização tem para oferecer aos clientes; “who” (clientes) - melhores modos de servir os clientes; “how” (processos) - como gerir os processos internos; “where” (organização) - posicionamento da organização no mercado. Este deve ser gerido através de metodologias ágeis, como ACM e Scrum (entre outros), pois envolve muita imprevisibilidade e necessita de uma adaptação constante. Este processo tem como foco o conhecimento dos intervenientes para que este avance e não sofra atrasos;

Processo gestão global: este processo permite controlar de forma global o projecto. Através deste será possível avaliar se os objectivos são cumpridos e quais as metas atingidas, não ficando este tipo de informações apenas para os processos respectivos. Assim, este pode ser visto como o processo topo da hierarquia permitindo ligação entre outros. Poderá ser gerido segundo um template/ modelo, pois não é sujeito a muita imprevisibilidade.

O estudo a desenvolver será focado neste projecto todavia tem como horizontes outros de diferentes tipos. Pretende-se desenvolver um modelo que se possa adaptar a diversos programas, de diferentes áreas de actividade.

Este projecto será desenvolvido no âmbito da dissertação do Mestrado Integrado em Engenharia Electrotécnica e de Computadores da Faculdade de Engenharia da Universidade do Porto.

1.4 Resultados esperados

4 Introdução

Com a elaboração desta dissertação prevê-se obter os seguintes resultados:

Estado da arte sobre gestão de projectos com elaboração de taxonomia abrangendo paradigmas de gestão, metodologias, modelos ferramentas e sistemas;

Mapa de processos PitVant; Modelo do domínio PitVant nas vertentes modelos dos processos, informação e

colaboração Análise e especificação dos processos (e regras) de planeamento e controlo do

projecto; Gestão da equipa; Análise dos casos de uso e especificação das interfaces do sistema de suporte à

equipa; Implementação, utilização e avaliação do sistema.

1.5 Metodologia utilizada

Dado o tema da dissertação e a necessidade do conhecimento nesta área da gestão de

projectos, decidiu-se iniciar esta dissertação com o desenvolvimento de um estado da arte focado na gestão, análise de projectos e actividades IDI. Desta forma existiu uma familiarização com diversas metodologias importantes para o desenrolar do trabalho de forma mais consciente e consistente, aumentando-se assim o “know-how” na área.

Após a pesquisa e estudo das metodologias e softwares existentes, irá ser realizada um estudo aprofundado do caso de estudo, projecto PitVant, com o intuito de perceber como a equipa trabalha, os requisitos necessários à interface, sugestões e dificuldades com as quais se deparam no seu dia-a-dia. Este é um passo crucial para todo o desenvolvimento que se segue, pois será este a base do mesmo.

Como desenvolvimento e implementação, vão ser elaborados modelos dos processos do projecto assim como modelos das interfaces. Estes modelos serão testados para que se perceba a sua utilidade, associada a cada processo. A utilidade será avaliada em conjunto com os elementos do projecto, e reajustados, na fase de testes, sempre que necessário para uma melhor adaptação às necessidades da equipa.

6 Metodologias de gestão de projectos, análise de projectos e actividades IDI

Capítulo 2

Estado da Arte

Metodologias de gestão de projectos, análise de projectos e actividades IDI

2.1 Estado da Arte Tomou-se como primeiro passo a pesquisa de princípios e conceitos relativos à gestão de

projectos e análise dos mesmos, sendo esta a essência deste capítulo. O estudo foi baseado na pesquisa de metodologias de gestão de projectos. Como resultado

deste estudo, surge este capítulo em que serão descritas as metodologias encontradas assim como também uma explicação de cada. Recorreu-se a ilustrações para uma melhor percepção dos métodos em análise podendo-se perceber também as etapas que cada um ostenta.

Nos dias que correm, as actividades de IDI são cada vez mais críticas para o sucesso das empresas, permitindo-lhes serem altamente competitivas nos mercados nacionais e internacionais.

Outro facto essencial é a utilização das metodologias ágeis, pois estas são mais adaptáveis às diferenças entre projectos, sendo esta adaptação reflectida na capacidade de reagir e na rapidez com que se chega ao produto final. Este tipo de metodologias baseado no conhecimento implica a existência de muita mais flexibilidade nos programas, menos rigidez nas datas, ou seja, fornecer mais liberdade aos envolventes para tomar as decisões certas no momento certo.

Os métodos apresentados neste capítulo serão importantes para o decorrer desta dissertação e serão aplicados conforme os processos existentes. No caso do processo missão, este poderá ser modulado segundo modelos predefinidos pois envolvem datas, intervenientes e não exigem conhecimento para de realizar um plano. Ao contrário deste, o processo

7

desenvolvimento de produto, este caracteriza-se pela elevada imprevisibilidade, mudanças e ajustes. Estas características levam a que não seja possível o uso de modelos predefinidos mas sim métodos ágeis, exigindo intervenção de conhecimento dos participantes e ajustes ao trabalho a realizar.

Como metodologias destaca-se o PMBOK que é uma referência a este nível devido a sua adaptação e à sua implementação através de 5 passos. O Scrum é também abordado pois transmite a ideia de acompanhamento cuidado do programa e o OPPM representação numa única página de toda a informação do projecto. Para além destes é de referir outros não menos importantes como XP, PDCA, etc.

Conclui-se que nem todos os processos puderam ser tratados segundo todas as metodologias existentes mas sim terão de ser escolhidas em função de cada processo, isto para que se realize um trabalho adequado, eficaz e eficiente. [2] [3]

2.2 Metodologias de gestão de projectos: Pesquisa

BPM: consiste numa metodologia de gestão de projectos que pode ser auxiliada por métodos, técnicas e ferramentas para: analisar, modelar, publicar, optimizar e controlar processos envolvendo recursos humanos, aplicações, documentos e outras fontes de informação. Permite às empresas identificarem os processos e tirarem vantagens competitivas disso. Serve também para proporcionar ao gestor uma maior facilidade de encontrar oportunidades de melhoria para o serviço prestado ao cliente, através de indicadores de desempenho. A metodologia permite que, através de uma execução e de um controlo eficaz, se consiga que os processos possam ser melhorados em qualquer uma das áreas da organização. Sempre que necessário são executados um serie de passos, constituindo o ciclo BPM. Esta metodologia apela à utilização de templates pois os programas/ processo são tidos como previsíveis. [4]

A imagem seguinte ilustra a metodologia BPM.


Figura 2.1 - Ciclo da metodologia BPM. [5]

ACM: permite que organizações com dados estruturados ou não executam

trabalho de uma maneira segura e mais transparente. Esta metodologia têm equipas de trabalho integradas que partilham conhecimento e colaboram em prol de um objectivo, o processo. Mas de maneira a ser atingido o objectivo deve existir uma hierarquia entre os trabalhadores e deadlines, pois de contrário existirá desorganização total e o processo não avançará. São envolvidos três paradigmas nesta metodologia: É um sistema produtivo que emprega e não apenas a estrutura a

organização e os processos. Através da interface torna-se um sistema de registo para as entidades do projecto. Todos os processos são completamente transparentes e plenamente editáveis;

Deve permitir aos utilizadores, não-técnicos, das organizações, poderem de forma transparente criar / consolidar os processos, conteúdo, iterações sociais e regras de negócios;

Move o processo de colheita de conhecimento para a análise do modelo, modelação e simulação na fase de execução do processo.

É possível verificar que a chave do sucesso está na combinação correcta entre ACM e BPM na resolução dos processos. Pois para obtermos controlo, visibilidade e entendimento real do processo necessitamos dessa combinação e flexibilidade. Com a combinação de ACM com BPM conseguimos responder a todo o tipo de processos. De salientar que o ACM surge na hierarquia após o BPM, na eventualidade de não ser possível a modelação de processos, pois envolve conhecimento. [4]

A imagem seguinte ilustra a metodologia ACM.

9

Figura 2.2 - Ciclo da metodologia ACM.

PMBOK: é um conjunto de práticas em gestão de projectos, constituindo a base

do conhecimento em gestão de projectos do PMI. Estas práticas são compiladas como se de um guia se tratasse, chamado de Guia do Conjunto de Conhecimentos em Gestão de Projectos, ou Guia PMBOK. [6] O Guia PMBOK orienta os gestores de projectos de forma a seguirem um conjunto de processos, constituindo 5 fases, descritas em seguida: Fase de INICIAÇÃO - fase onde iniciamos oficialmente o projecto.

Pressupõem entradas, ferramentas e saída. Todos os envolvidos nesta fase reconhecem que o projecto deve iniciar e comprometem-se a executá-lo;

Fase de PLANEAMENTO - fase responsável por detalhar tudo aquilo que será realizado no projecto, incluindo cronogramas, interdependências entre actividades, alocação de recursos envolvidos, análise de custos, etc., para que, no final dessa fase, o projecto esteja suficientemente detalhado para ser executado, sem dificuldades e imprevistos. Nessa fase, os planos auxiliares de comunicação, qualidade, riscos, suprimentos e recursos humanos também são desenvolvidos;

Fase de EXECUÇÃO - fase que materializa tudo aquilo que foi planeado anteriormente. Qualquer erro cometido nas fases anteriores fica evidente durante este processo;

Fase de CONTROLO - fase que acontece paralelamente à fase de Execução. Tem como objectivo acompanhar e controlar aquilo que está a ser realizado, de modo a propor acções correctivas e preventivas, no menor espaço de tempo possível, após a detecção da anormalidade;

Fase de ENCERRAMENTO - fase onde os trabalhos são avaliados, através de uma auditoria interna ou externa (terceiros), os livros e documentos do projecto são terminados e todas as falhas ocorridas durante o projecto são


discutidas e analisadas para que erros similares não ocorram em novos projectos. São também identificadas e seleccionadas estratégias como "lições aprendidas". [7] [8]

A imagem seguinte ilustra a metodologia PMBOK.

Figura 2.3 - Ciclo da metodologia PMBOK. [7]

O Scrum: é um processo de desenvolvimento iterativo e incremental para gestão

de projectos e desenvolvimento ágil de software. Este processo não descreve o que fazer em cada situação e é utilizado para trabalhos complexos nos quais é impossível prever tudo o que irá ocorrer. Apesar do Scrum ter sido desenvolvido para gestão de projectos de software, este pode ser utilizado em equipas de manutenção de software ou como uma abordagem geral de gestão de projectos/programas. Esta metodologia caracteriza-se por se realizar uma reunião, no máximo de 4 em 4 semanas, período este denominado de Sprint. Este método consiste em partir um grande processo em pequenos blocos e trabalhá-los. No fim do tempo estipulado (4 semanas no máximo) para realização do bloco, será realizada outra reunião onde se verificará se o trabalho se completou e consequentemente seguir para o próximo bloco de trabalho. Este processo é realizado até se terminarem os blocos constituintes do processo completo. [9]

A seguinte imagem ilustra a metodologia Scrum.

11

Figura 2.4 – Ciclo da metodologia Scrum. [9]

One page project manager: esta metodologia caracteriza-se por se representar

numa única página toda a informação do projecto em análise, facilitando às pessoa envolvidas obter uma visão rápida e objectiva do projecto em que estão inseridas. As informações presentes nesta página de projecto podem ser: Intervenientes; Missões; Tarefas; Deadlines; Milestones; Precedências; Custos; Output’s; Etc.

A seguinte imagem ilustra a metodologia One page project manager.


Figura 2.5 – Exemplo de uma página com informação total do projecto.[10]

XP: é uma metodologia ágil para equipas pequenas e médias e que desenvolvam

produtos com requisitos vagos e em constante mudança. Para isso, adopta uma estratégia de constante acompanhamento e realização de vários ajustes (pequenos) durante o desenvolvimento do produto. Os cinco valores fundamentais da metodologia XP são: comunicação, simplicidade, feedback, coragem e respeito. De entre as variáveis de controlo de projectos (custo, tempo, qualidade e finalidade) há um foco explícito em finalidade. Neste sentido, recomenda-se o foco na prioridade de funcionalidades que representem maior valor possível para o projecto. A XP incentiva o controlo da qualidade como variável do projecto. [11] [12] [13]

A seguinte imagem ilustra a metodologia XP.

13

Figura 2.6 - Metodologia XP. [13]

PDCA: é um ciclo de desenvolvimento que tem foco na melhoria contínua.

O PDCA foi introduzido no Japão após a guerra, idealizado por Shewhart e divulgado por Deming, quem efectivamente o aplicou. Inicialmente, utilizou-se este método para fins estatísticos e métodos de amostragem. Este método é aplicado para se atingir resultados dentro de um sistema de gestão e pode ser utilizado em qualquer empresa de forma a garantir o sucesso nos negócios, independentemente da área de actuação da empresa. O ciclo tem por princípio tornar mais claros e ágeis os processos envolvidos na execução da gestão, como por exemplo na gestão da qualidade, dividindo-a em quatro principais passos. Este começa pelo planeamento, em seguida a acção ou conjunto de acções planeadas são executadas, verifica-se se o que foi realizado esta de acordo com o planeado, constantemente e repetidamente (ciclicamente), e toma-se uma acção para eliminar defeitos no produto ou na execução. Os passos são os seguintes:

Plan (planeamento): estabelecer uma meta ou identificar o problema (um problema tem um sentido); analisar o fenómeno (analisar os dados relacionados ao problema); analisar o processo (descobrir as causas fundamentais dos problemas) e elaborar um plano de acção;

Do (execução): realizar e executar as actividades conforme o plano de acção;

Check (verificação): monitorizar e avaliar periodicamente os resultados; avaliar processos e resultados, confrontando-os com o planeado, objectivos, especificações e estado desejado, consolidando as informações;

Act (acção): Agir de acordo com o avaliado e de acordo com os relatórios, eventualmente determinar e confeccionar novos planos de acção, de forma


a melhorar a qualidade, eficiência e eficácia, aprimorando a execução e corrigindo eventuais falhas. [14]

A seguinte imagem ilustra a metodologia PDCA.

Figura 2.7 - Metodologia PDCA. [15]

Manual de gestão IDI: apesar de ser um manual, pode ser visto como um método

para alcançar uma gestão segura e controlada. O objectivo deste manual passa por identificar as actividades que contribuem para o aumento de competitividade e criação de valor, através da implementação de processos de inovação (implementação/criação de soluções de valor económico e social através de exploração de oportunidades, reforçando a capacidade competitiva). Deste manual há que destacar alguns tipos de inovação: Produto: introdução no mercado de produtos/serviços novos ou

melhorados a nível de especificações técnicas, componentes, interfaces, software, etc;

Processo: introdução de novos ou significativamente melhorados processos de produção ou logística de bens ou serviços, com alterações significativas de técnicas, equipamentos ou software (ex.: novo equipamento de automação de uma linha de produção, novos mecanismos de monitorização por GPS nos serviços de transporte);

Organizacional: implementação de novos métodos organizacionais na prática do negócio (implementação de novos métodos que ajudem na partilha de aprendizagem e conhecimento), organização do trabalho (novos métodos de distribuição de responsabilidades e tomadas de decisão) e/ou relações externas (novos métodos de gerir relações com outras firmas e instituições);

Marketing: implementação de novos métodos de marketing, envolvendo melhorias significativas no design do produto ou embalagem, preço, distribuição e promoção (garantir uma maior satisfação das necessidades dos clientes, reposicionar o produto no mercado e aumentar as vendas).

Deste manual, destaca-se também actividades relacionadas com a gestão do conhecimento, tais como:

15

Inovação: actividades de carácter científico, tecnológico, organizacional, financeiro, etc, direccionadas para implementação de inovações;

I&D: todo o trabalho criativo realizado de forma sistemática com o objectivo de aumentar o conhecimento do homem, cultura e sociedade, bem com o seu uso para inventar novas aplicações: Investigação Fundamental - trabalhos experimentais ou teóricos,

desenvolvidos com a finalidade de obtenção de novos conhecimentos técnicos e científicos, sem objectivo de aplicação definido;

Investigação aplicada – trabalhos de investigação originais, desenvolvidos com o objectivo de criar novo conhecimento, direccionado claramente para uma aplicação ou objectivo bem definido;

Desenvolvimento experimental – trabalho sistemático desenvolvido com utilização do conhecimento gerado na investigação e experiência, de forma a criar novos ou melhorados materiais ou dispositivos, para instalação de novos processos, sistemas ou serviços, ou melhorar os existentes. [16]

A seguinte imagem ilustra o manual de IDI.

Figura 2.8 - Actividades do manual de IDI. [16]

DECLARE: é um sistema de gestão de workflow (WFMS) baseado numa linguagem

de modelação de processos para o desenvolvimento de modelos que descrevam processos distribuídos, sem afectar as características fundamentais dos WFMS tais como: Apoio ao utilizador; Verificação de modelos; Análise de situações passadas;


Alteração de modelos em run-time; Etc.

Como os WFMS são tipicamente rígidos, é difícil às organizações manterem a flexibilidade dos seus processos de negócio. O grande entrave das linguagens de workflow é que obrigam o utilizador a modelar o processo como um todo, não havendo grande flexibilidade em intervir posteriormente nas suas actividades constituintes de forma individual. Este método possui algumas vantagens, entre elas: Suporta processos distribuídos; Uso de uma linguagem assente numa lógica temporal para o

desenvolvimento e execução dos modelos/ mapas de processos; Mantém as funcionalidades dos tradicionais WFMS; Fornece recomendações ao utilizador enquanto o processo é executado.

O DECLARE trabalha com duas outras ferramentas: YAWL: WFMS open source que lida com as partes estruturadas do processo,

ficando o DECLARE responsável pelas partes não estruturadas; [17] ProM: Analisa os processos executados anteriormente pelo Declare e emite

recomendações. Este modelo para além das ferramentas atrás referidas, é também constituído por 3 módulos: Designer - sistema de modelação usado para as definições do sistema e

desenvolvimento de processos; Framework - comunicação entre o designer, o YAWL e o ProM, e permite

alteração dos modelos em run time; Worklist - ferramenta que permite aos utilizadores executar o processo e

receber recomendações. A seguinte imagem ilustra a metodologia DECLARE.

Figura 2.9 – Metodologia DECLARE.

17

A tabela abaixo surge do estudo dos métodos acima apresentados, sendo um pequeno resumo destes, onde são apresentadas as características específicas de cada método.

Tabela 1 – Tabela comparativa das metodologias.

Método Vantagens Desvantagens

BPM

Facilidade em encontrar oportunidades de melhoria para o serviço prestado ao cliente, através de indicadores de desempenho

Não pode ser utilizado em processos que tenham elevado índice de imprevisibilidade

ACM

Ajuda no desenvolvimento dos intervenientes ao apelar ao conhecimento destes e permite uma melhor e mais rápida adaptação as situações em análise

Pode levar a atrasos devido à dependência do conhecimento dos intervenientes, como qualquer metodologia ágil

PMBOK Estruturação através de 5 fases distintas

Complexo para projectos pequenos

Scrum Permite acompanhamento mais próximo do projecto e garante processo iterativo

Pode levar a atrasos do projecto global devido ao processo iterativo

OPPM Permite uma visão global do projecto, das tarefas e prazos, apesar do pouco detalhe

Devido à quantidade de informação pode tornar-se confuso

XP

Incentiva o controlo da qualidade

Como metodologia ágil o seu sucesso depende da maturidade das equipas envolvidas, pois exige adequação constante

PDCA

Foco na melhoria contínua e torna processos mais claros e ágeis

A melhoria dos processos pode levar a um número elevado de utilizações do ciclo PDCA, o que leva a atrasos

Manual de gestão IDI

Permite uma boa estruturação do processo de gestão, alcançando-se uma gestão segura e acompanhada

Pode levar a atrasos do projecto devido à sua evolução depender do conhecimento dos elementos das equipas

DECLARE

Fornece recomendações e suporta processos distribuídos

É tipicamente rígido, o que dificulta às organizações manterem a flexibilidade dos seus processos de negócio


2.3 Modelos para projectos: Pesquisa

Swimlanes: é um elemento visual utilizado em diagramas de fluxos de processo, ou fluxogramas, que distinguem visualmente as responsabilidades dos sub-processos de um modelo de negócio. As pistas podem ser organizadas horizontal ou verticalmente. As setas entre as pistas representam como a informação ou material é passado entre os sub-processos. Este modelo de representação permite uma melhor visualização do fluxo, ficando pouco perceptível quando se pretende demonstrar muitas condições. Nestes modelos, a cada actor do processo corresponde uma pista (“lane”) onde são colocadas as tarefas a executar por esse actor. Estes modelos podem ser divididos em 2 tipos, correspondendo a diferentes níveis de detalhe: Modelo dos Hands–off; Modelo detalhado do fluxo.

Nos 2 casos trata-se de modelos swimlane mas com ênfase em aspectos diferentes. No caso do modelo hands-off o destaque está nos actores envolvidos no processo e nas transferências de responsabilidade entre eles. Cada intervenção no processo de um actor, por mais complexa que seja, é representada por uma única tarefa. Já no modelo de fluxo, a ênfase está na representação do fluxo de trabalho e no detalhe das actividades que não são muito exploradas no modelo hands-off. O seu principal objectivo é compreender as actividades chave que determinam o desempenho do processo. Quando comparada com outras notações (como, por exemplo, os diagramas de actividade UML e os diagramas BPMN), a notação aqui apresentada para os swimlanes é mais simples e intuitiva, o que, muitas vezes, se justifica porque é fundamental que os modelos sejam o mais intuitivo possível quando se pretende envolver colaboradores não especializados na análise dos processos. Estes modelos são muito intuitivos mas também apresentam algumas limitações que impedem (ou pelo menos dificultam) a sua utilização em certas situações.

A seguinte imagem ilustra o modelo swimlane.

19

Figura 2.10 – Ilustracção do modelo Swimlane. [18]

Matriz de responsabilidades: estes modelos do tipo matriz são, sobretudo,

adequados nas situações em que a sequência de actividades é linear e em que cada actividade há vários intervenientes com diferentes graus de responsabilidade. Como grau de responsabilidades, consideram-se os seguintes 4 níveis: Responsável: pessoa que responde pela obtenção dos resultados

pretendidos; Executante: pessoa ou grupo que vai executar a tarefa; Informado: pessoa ou grupo que é mantida informada do avanço e dos

resultados do processo; Consultor: pessoa ou grupo a quem é pedido parecer relativamente a

aspectos específicos do processo. A seguinte imagem ilustra o modelo matriz de responsabilidades.


Figura 2.11 – Ilustração do modelo tipo matriz.

Pert/ CPM: são utilizados em planeamento e controlo de programas. O modelo Pert tem várias semelhanças com o CPM, o que faz com que o termo Pert/CPM seja utilizado frequentemente como apenas uma única técnica. Como exemplo de programas onde estes tipos de modelos podem ser utilizados temos: Construção de plantas; Pesquisa e desenvolvimento de produtos; Produção de filmes; Construção de navios; Instalação de sistemas de informação; Condução de campanhas publicitárias, entre outras.

Cada um destes programas possui três características que são essenciais para a utilização do Pert/ CPM: São constituídos por um conjunto bem definido de actividades cuja

finalização corresponde ao fim do projecto; As actividades podem começar ou parar independentemente umas das

outras, numa dada sequência (o que elimina os processos contínuos em que as actividades ou operações se seguem obrigatoriamente umas às outras sem tempo de separação significativo entre elas);

As actividades são ordenadas, isto é, devem ser realizadas numa sequência tecnológica bem determinada.

O Pert/ CPM utilizam principalmente os conceitos de redes (Grafos) para planear e visualizar a coordenação das actividades do projecto/ programa. Enquanto o Pert corresponde ao cálculo a partir da média ponderada de três durações possíveis de uma actividade (optimista, mais provável e pessimista), o CPM é um método de detecção do caminho crítico dada uma sequência de actividades, isto é, quais as actividades de uma sequência que não podem sofrer alteração de duração sem que isso se reflicta na duração total de programa. Destacam-se três fases importantes na utilização deste método:

21

Planear: divisão do projecto em actividades; Programar: determinação das relações de dependência entre as

actividades; Controlar: representação gráfica das actividades e do seu

relacionamento.[19] [20] A seguinte imagem ilustra o modelo Pert/ CPM.

Figura 2.12 - Ilustração do modelo Pert/CPM. [19]

Gantt: também designado por gráfico de barras, é constituído por um sistema de

eixos coordenados, representando-se no eixo das ordenadas as actividades e no eixo das abcissas o tempo (normalmente definido em dias, semanas ou meses). Para além das actividades a realizar, será necessário também a sua respectiva duração. Em geral, as actividades distintas alinham-se na vertical. As actividades dependentes temporalmente podem representar-se em sequência horizontal. O controlo do plano é feito de forma simples, através da representação de uma linha vertical, traçada na data que se pretende analisar. Em certos casos, existem regras especiais, para permitirem o deslocamento desta linha para qualquer posição que se pretende observar. As folgas das actividades são representadas como extensão gráfica da respectiva barra da actividade, mas a cheio. As actividades críticas são representadas a cor diferente ou com um padrão. Em seguida, são mostrados as vantagens e desvantagens deste método de modulação. Vantagens: Planeamento fácil, simples e claro; Fácil adição de novas actividades; Fácil eliminação de actividades; Análise fácil, directa e imediata; Orientado para o parâmetro temporal.

Desvantagens:


Dificuldade na detecção das inter-relações entre actividades (dependências entre actividades);

Difícil detectar actividades inúteis; Difícil estimativa de tempos; Apenas é possível efectuar um controlo genérico (questões do tipo: “que

outras actividades podem prosseguir antes de começar a actividade x”); Modificações profundas provocam o redesenho do plano. [21]

A seguinte imagem ilustra o modelo Gantt.

Figura 2.13 - Ilustração do diagrama de Gantt. [21]

WBS: é uma ferramenta utilizada para definir e agrupar os elementos de um projecto de uma forma que definir a organização deste. Os elementos deste diagrama de trabalho podem ser um produto, dados, serviço, ou qualquer combinação. A WBS também fornece o quadro necessário para estimar o custo detalhado e controlo em conjunto com o fornecimento de orientações para o desenvolvimento do cronograma e controlo. Assim, este modelo para projectos tem como objectivo desmultiplicar o projecto total em sub-projectos de forma a ser mais fácil entender cada um, percebendo-se/ executando-se assim melhor o projecto global. [22]

A seguinte imagem ilustra o modelo WBS.

23

Figura 2.14 - Ilustração do diagrama WBS. [23]

SBS: define quais os subsistemas que constituem o projecto. Cada um subsistema fica com um número de requisitos pré-estabelecidos e com outros subsistemas encadeados. Através deste método de organização é possível definir uma hierarquia entre os sistemas envolvidos num programa.

A seguinte imagem ilustra o modelo SBS.

Figura 2.15 - Ilustração do diagrama SBS.

Fluxograma: é um tipo de diagrama que visa a representação esquemática de um

processo. Pode ser tido como um documento onde são descritos os passos necessários para a execução de um processo do sistema.


Esta é uma das sete ferramentas da qualidade, dai realçando-se a sua importância. É muito utilizada em fábricas e industrias para a organização de produtos e processos. O fluxograma dá uma ideia do desenrolar do processo no seu conjunto, mas não contém todos os detalhes relevantes sobre os processos como os responsáveis, tempos e datas. De maneira a melhorar a informação fornecida por este tipo de diagramas, podem ser utilizadas cores que relacionem as actividades com os actores. Por vezes torna-se difícil seguir o fluxo do processo, principalmente quando o fluxograma é demasiado complexo e apresenta muitas condições. Este tipo de diagramas são constituídos por vários símbolos, símbolos estes com significados diferentes. Temos na seguinte figura a ilustração de um fluxograma assim como também alguns dos símbolos utilizados neste tipo de diagramas.

A seguinte imagem ilustra o diagrama fluxograma.

Figura 2.16 - Ilustração do Fluxograma e símbolos. [24]

2.4 Softwares de gestão/ modelação de projectos: Pesquisa

MS Project: software criado pela Microsoft. Possui vários focos: tempo (datas, duração do projecto, calendário de trabalho), gráfico de Gantt, modelo probabilístico (para cálculos relacionados com o planeamento), diagrama de Rede, custos (fixos, não fixos e outros) e uma gama de relatórios. É um óptimo software para gestores, administradores e coordenadores. A interface padronizada da Microsoft facilita para os iniciantes a familiarização com o produto.

A seguinte imagem ilustra a interface do software MS Project.

25

Figura 2.17 - Ilustração da interface do MS Project. [25]

Redmine: é um software livre, com a função de gerir projectos online (Web). Contém calendário e gráficos de Gantt para auxílio na representação visual dos projectos e suas deadlines (prazos de entrega). Este software permite trabalhar diversos projectos em simultâneo. O design do Redmine foi influenciado pelo Trac1.

A seguinte imagem ilustra a interface do software Redmine.

1 Trac é uma simples ferramenta, open source e de interface Web para controlo de mudanças em

projectos de desenvolvimento de software. O objectivo do software é ajudar o programador a verificar

essas mudanças, entender o porquê de cada uma e qual o seu impacto no projecto como um todo.


Figura 2.18 - Ilustração da interface do Redmine. [26]

TSP: Team Software Process é utilizado como orientação para equipas de

engenharia que estão a desenvolver produtos intensivos. A utilização do TSP pode ajudar as organizações a estabelecer práticas de engenharia evoluídas, disciplinadas, seguras e confiáveis em menos tempo e a custos menores. Este software reduz o número de defeitos em 80% ou mais, assim tornando os sistemas produzidos mais confiáveis e com menor probabilidade de terem defeitos que levem a preocupações graves. Sendo assim, o TSP demonstra "como fazer" aplicações segundo os melhores princípios e melhores práticas. Inclui também muitos conceitos, importantes em projectos, tais como: Gestão de equipas auto-disciplinadas; Quadro de avaliação integrada; Qualidade e sistema de gestão; Apoio por treino e ferramentas. [27]

@task: é um software de gestão de projecto que ajuda as empresas a realizar o

seu trabalho. Este permite que centenas de empresas melhorem o fluxo de trabalho e produtividade. Características como gráficos de Gantt interactivos, calendário e listas de grupos do projecto são concebidos para minimizar o downtime e fazer a gestão de dados mais facilmente. Permite ainda o controlo de tempo de forma fácil, com capacidade de ligação a um dispositivo móvel que dá acesso aos projectos desde que existe internet. [28]

Microsoft Visio: é um software para criação de diagramas. O ponto forte deste software é os diagramas técnicos e profissionais, com imagens vectoriais, que podem ser ampliados e manipulados com facilidade. O Visio pode ser utilizado para efectuar diagramas de diversos tipos, como organogramas, fluxogramas,

27

modelagem de dados (usando UML, por exemplo), diagramas de redes, plantas baixas, cartazes, etc. O Visio pode ser considerado um intermediário entre um programa de CAD (especializado em desenho vectorial de alta precisão para engenharia) e um programa de desenho artístico vectorial. A flexibilidade, a simplicidade de uso e a qualidade das ferramentas tornam este software excelente para aplicações rápidas, rascunhos, e diagramas de uso pessoal ou profissional.

A seguinte imagem ilustra a interface do software Microsoft Visio.

Figura 2.19 - Ilustração da interface do Microsoft Visio. [29]

Bezagi: é uma solução de BPM que permite que as organizações possam automatizar, executar e melhorar os seus processos de negócio, através de um ambiente gráfico e sem a necessidade de programação. Neste software encontramos todas as informações e os recursos necessários para automatizar processos. Este software permite representação de diversos diagramas (swinlanes, fluxogramas, SBS, etc), diagramas esses que permitem demonstrar várias perspectivas do projecto, levando a que seja mais fácil encontrar possíveis melhorias, defeitos e novos processos.

A seguinte imagem ilustra a interface do software Bezagi.


Figura 2.20 - Ilustração da interface do Bizagi. [30]

2.5 Ferramentas de suporte

TO-DO list: é uma ferramenta onde é mostrada a lista de tarefas associadas a um projecto, assim como os intervenientes, data de início e fim, duração, prioridade e ainda uma coluna que indica a percentagem da tarefa já realizada. Esta coluna deve ser actualizada pelos intervenientes, para que os elementos do projecto estejam informados do estado das tarefas.

A seguinte imagem ilustra a ferramenta.

29

Figura 2.21 - Ilustração da ferramenta TO-DO list.

Checklist: é um tipo de apoio ao trabalho informal e é utilizado para reduzir o

insucesso, compensando eventuais limites da memória humana e atenção. Oferece um grande auxílio ao garantir a coerência e a realização de uma tarefa.

A seguinte imagem ilustra a ferramenta.

Figura 2.22 - Ilustração da ferramenta do Checklist. [31]


2.6 Conclusões

A elaboração deste capítulo, referente ao Estado da Arte, teve por objectivo o conhecimento e familiarização com conceitos relativos a gestão de projectos e análise dos mesmos. Este estudo foi de elevada importância para aumentar o conhecimento na área assim como também servir de apoio/base para o desenvolvimento da dissertação.

A gestão de projectos é importante para o sucesso destes e pode fazer a diferença entre se atingir ou não os objectivos propostos. Existe uma dificuldade imensa dentro das organizações relacionado com a gestão dos seus programas, dificuldades estas relacionadas com: comunicação, gestão de recursos e materiais, repositórios, liderança, planeamentos, etc. Estes são pontos críticos nos projectos e que deveram ser colmatados ou reduzidos.

Apurou-se que existe um elevado número de metodologias possíveis, cada uma com características próprias, ostentando vantagens e desvantagens. Estas vantagens e desvantagens encontram-se na Tabela 1, existente neste capítulo.

Desta pesquisa destacam-se as metodologias ágeis (Scrum, ACM, XP). Estas são de extrema importância em processos onde exista elevada imprevisibilidade e onde é necessário haver adaptação constante para se atingir os objectivos de forma eficaz.

Nem todas as metodologias podem ser utilizadas em todos os processos. Devem-se aplicar se possível e de forma ponderada, sempre com o horizonte do sucesso. Esta deve de ser uma verdade sempre presente no nosso pensamento.

31

Referências

[1] Gestão de projectos. Disponivel em http://www.google.pt/url?sa=t&source=web&cd=1&ved=0CBsQFjAA&url=http%3A%2F%2Fwww.3sector.net%2Fequalificacao%2Fsrc_cdroms%2Fconcepcao_avaliacao_gestao_projectos%2Flinks%2FGestao_de_Projectos.ppt&rct=j&q=metodologias%20gest%C3%A3o%20de%20projectos&ei=Fi_4TNbICYa08QP19v34Cg&usg=AFQjCNF3B9u6ix7nX0faTFlxv0fX8RJXFg&sig2=YZ8FR4JjycGTN9IsaHR3TQ. Acedido em 2 de Dezembro de 2010.

[2] Benchmarking e Boas Práticas. Disponivel em http://www.iapmei.pt/iapmei-bmkindex.php. Acedido em 27 de Novembro de 2010.

[3] Boas práticas de gestão de inovação. Disponivel em http://www.apcer.pt/arq/fich/Apresenta__o_COTEC_-_Braga.pdf. Acedido em 27 de Novembro de 2010.

[4] K. D. Swenson, Mastering the Unpredictable: How Adaptive Case Management Will Revolutionize the Way That Knowledge Workers Get Things Done, 2010.

[5] BPM. Disponivel em http://www.acg-usa.com/itap/Image/business_process_management.jpg. Acedido em 13 de Fevereiro de 2011.

[6] Project Management Institute. Disponivel em http://www.ogerente.com.br/. Acedido em 3 de Dezembro de 2010.

[7] Project Management Body of Knowledge. Disponivel em http://www.ogerente.com.br/. Acedido em 3 de Dezembro de 2010.

[8] Project Management Body of Knowledge. Disponivel em http://www.12manage.com/methods_pmi_pmbok_pt.html. Acedido em 30 de Janeiro de 2011.

[9] Scrum. Disponivel em http://www.mountaingoatsoftware.com/system/asset/file/70/ScrumMediumLabelled.png. Acedido em 2 de Dezembro de 2010.

[10] One page project manager. Disponivel em http://www.mpug.com/ProjectNetworkImages/Clark_Figure_1.jpg. Acedido em 2 de Dezembro de 2010.

[11] Extreme Programming. Disponivel em http://adonaimedrado.pro.br/principal/index.php?option=com_content&view=article&id=60&Itemid=89. Acedido em 30 de Janeiro de 2011.

32 Referências

[12] Extreme Programming. Disponivel em http://en.wikipedia.org/wiki/Extreme_Programming. Acedido em 27 de Janeiro de 2011.

[13] Extreme Programming. Disponivel em http://www.extremeprogramming.org/. Acedido em 2 de Dezembro de 2010.

[14] PDCA. Disponivel em http://pt.wikipedia.org/wiki/Ciclo_PDCA. Acedido em 2 de Fevereiro de 2011.

[15] PDCA. Disponivel em http://2.bp.blogspot.com/__0v65Qj-Qag/TQ7U_0EWfPI/AAAAAAAABPU/V87GDa1w-CY/s1600/pdca-plan-do-check-act.png. Acedido em 1 de Fevereiro de 2011.

[16] I. P. C. Portugal, Identificação e Classificação das Actividades de IDI. [17] YAWL. Disponivel em http://pt.wikipedia.org/wiki/YAWL. Acedido em 2 de Fevereiro

de 2011. [18] Swimlane. Disponivel em http://www.swimlaneflowcharts.com/wp-

content/uploads/2008/11/swimlane-example-before.jpg. Acedido em 1 de Fevereiro de 2011.

[19] PERT/ CPM. Disponivel em http://www2.ufp.pt/~lmbg/cadeiras/gst_cap7.pdf. Acedido em 5 de Fevereiro de 2011.

[20] PERT. Disponivel em http://pt.wikipedia.org/wiki/PERT. Acedido em 5 de Fevereiro de 2010.

[21] Gantt. Disponivel em http://twiki.fe.up.pt/pub/ERSS0708/Planeamento_G2/diagramaGantt.png. Acedido em 5 de Fevereiro de 2011.

[22] Work Breakdown Structure. Disponivel em http://en.wikipedia.org/wiki/Work_breakdown_structure. Acedido em 25 de Janeiro de 2011.

[23] WBS. Disponivel em http://www.chambers.com.au/sample_p/wbs_2.gif. Acedido em 12 de Fevereiro de 2011.

[24] Fluxograma. Disponivel em http://upload.wikimedia.org/wikipedia/commons/4/46/LampFlowchart_pt.svg. Acedido em 12 de Fevereiro de 2011.

[25] MS Project. Disponivel em http://www.filebuzz.com/software_screenshot/full/20403-decisioncharts_for_microsoft_project.jpg. Acedido em 31 de Janeiro de 2011.

[26] Redmine. Disponivel em http://techsivam.files.wordpress.com/2010/09/issue_list.png. Acedido em 31 de Janeiro de 2011.

[27] Team Software Process. Disponivel em http://www.sei.cmu.edu/tsp/. Acedido em 31 de Janeiro de 2011.

[28] @Task. Disponivel em http://www.attask.com/. Acedido em 4 de Dezembro de 2010. [29] Microsoft Visio. Disponivel em http://www.qweas.com/downloads/business/office-

suites-tools/scr-microsoft-office-visio-professional-2007.jpg. Acedido em 1 de Fevereiro de 2011.

[30] Bizagi. Disponivel em http://4.bp.blogspot.com/_uiVDIgVcE-o/TL4J2VPM_uI/AAAAAAAAAFs/txNw3EY2PTs/s400/bizagiprocessmodeler1410-m4.jpg. Acedido em 31 de Janeiro de 2011.

33

[31] Checklist. Disponivel em http://4.bp.blogspot.com/_tdYo9hTG4-s/STUtgPosqhI/AAAAAAAAACs/uOx3RfnAehQ/s400/checklist.bmp. Acedido em 1 de Fevereiro de 2011.

análise e desenvolvimento de sistema de gestão de...

Documents