You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
188 lines
8.6 KiB
188 lines
8.6 KiB
12 years ago
|
<chapter id="definitions">
|
||
|
<chapterinfo>
|
||
|
<authorgroup>
|
||
|
<author
|
||
|
><firstname
|
||
|
>Anne-Marie</firstname
|
||
|
> <surname
|
||
|
>Mahfouf</surname
|
||
|
> <affiliation
|
||
|
> <address
|
||
|
><email
|
||
|
>annma@kde.org</email
|
||
|
></address>
|
||
|
</affiliation>
|
||
|
</author>
|
||
|
<author
|
||
|
><firstname
|
||
|
>Raphael</firstname
|
||
|
> <surname
|
||
|
>Langerhorst</surname
|
||
|
> <affiliation
|
||
|
> <address
|
||
|
><email
|
||
|
>raphael.langerhorst@kdemail.net</email
|
||
|
></address>
|
||
|
</affiliation>
|
||
|
</author>
|
||
|
<othercredit role="translator"
|
||
|
><firstname
|
||
|
>José</firstname
|
||
|
><surname
|
||
|
>Pires</surname
|
||
|
><affiliation
|
||
|
><address
|
||
|
><email
|
||
|
>jncp@netcabo.pt</email
|
||
|
></address
|
||
|
></affiliation
|
||
|
><contrib
|
||
|
>Tradução</contrib
|
||
|
></othercredit
|
||
|
>
|
||
|
</authorgroup>
|
||
|
</chapterinfo
|
||
|
>
|
||
|
<title
|
||
|
>Definições</title>
|
||
|
|
||
|
<sect1 id="gantt">
|
||
|
<title
|
||
|
>Gráficos de Gantt</title>
|
||
|
<para
|
||
|
>Um gráfico ou diagrama de Gantt é um tipo popular de gráficos de barras, que pretende mostrar a calendarização de tarefas ou actividades, da forma como ocorrem ao longo do tempo. Ainda que o diagrama de Gantt não indicasse inicialmente as relações entre as tarefas, isso tornou-se comum na utilização normal, dado que a calendarização e as dependências entre as tarefas podem ser identificadas. </para>
|
||
|
<para
|
||
|
>Na gestão de projectos, um diagrama de Gantt pode mostrar quando os elementos terminais do projecto começam e acabam, resumir os elementos (mostrados) ou as dependências entre elementos terminais (não mostrado). Um elemento terminal é definido como sendo a menor tarefa registada como parte do esforço do projecto. As tarefas aparecem numa página como barras. A página é disposta de forma a que o tempo aumenta à medida que se move pela página. A data/hora de início de uma tarefa é indicada pelo ponto da página onde a barra começa e a sua duração é indicada pelo comprimento da barra. </para>
|
||
|
<para
|
||
|
>Desde a introdução inicial dos diagramas de Gantt, estes tornaram-se uma norma da indústria como uma ferramenta-chave da gestão de projectos para representar as fases, tarefas e actividades que estão agendadas como parte de uma Estrutura de Divisão de Trabalho (WBS) ou delineação temporal das tarefas. </para>
|
||
|
<para
|
||
|
>O formato inicial do gráfico foi desenvolvido por Henry L. Gantt (1861-1919) em 1910 (veja em <quote
|
||
|
>Work, Wages and Profit</quote
|
||
|
> de H. L. Gantt, publicado pela The Engineering Magazine, NY, 1910). </para>
|
||
|
</sect1>
|
||
|
|
||
|
<sect1 id="wbs">
|
||
|
<title
|
||
|
>Estrutura de Divisão de Trabalho (WBS)</title>
|
||
|
<para
|
||
|
>Na gestão de projectos, uma estrutura de divisão de trabalho (WBS) é uma estrutura em árvore exaustiva e hierárquica (do mais genérico para o mais específico) dos itens a entregar e das tarefas que precisam ser efectuadas para completar um projecto. </para>
|
||
|
<para
|
||
|
>O intuito de um WBS é identificar os elementos terminais (os itens actuais a serem feitos num projecto). Como tal, a WBS serve como base para a maior parte do planeamento do projecto. </para>
|
||
|
<para
|
||
|
>Uma regra de algibeira útil é que qualquer projecto consegue ser dividido entre 10 e 20 tarefas. </para>
|
||
|
<para
|
||
|
>A estrutura de divisão do trabalho é uma ferramenta muito comum da gestão de projectos. Muitos contratos para o Governo dos Estados Unidos obrigam a estruturas de divisão de trabalho. </para>
|
||
|
<para
|
||
|
>Veja a secção <xref linkend="configure-wbs"/> para saber como configurar a sua WBS. </para>
|
||
|
</sect1>
|
||
|
|
||
|
<sect1 id="float">
|
||
|
<title
|
||
|
>Flutuação</title>
|
||
|
<para
|
||
|
>A flutuação na gestão de projecto é a quantidade de tempo que um elemento terminal numa rede do projecto consegue ser atrasado, sem causar um atraso em: <itemizedlist
|
||
|
> <listitem
|
||
|
><para
|
||
|
>elementos terminais subsequentes (flutuação livre)</para
|
||
|
></listitem
|
||
|
> <listitem
|
||
|
><para
|
||
|
>data de fim do projecto (flutuação total).</para
|
||
|
></listitem
|
||
|
> </itemizedlist
|
||
|
> A flutuação é também chamada, em calão, de 'cagaço'. </para>
|
||
|
</sect1>
|
||
|
|
||
|
<sect1 id="task">
|
||
|
<title
|
||
|
>Tarefa</title>
|
||
|
<para
|
||
|
>Uma tarefa é parte de um projecto que tem de ser cumprida dentro de um determinado período de tempo. As tarefas podem estar associadas em conjunto, de modo a criar Dependências. </para>
|
||
|
<para
|
||
|
>As tarefas tomam lugar sobre um período de tempo e consomem normalmente recursos. </para>
|
||
|
<para
|
||
|
>Uma tarefa é considerada crítica quando tiver uma flutuação nula ou negativa. </para>
|
||
|
<para
|
||
|
>No &kplato;, cada tarefa tem um ID de tarefa, um nome e um responsável. O tempo, o custo e os recursos atribuídos podem também ser definidos na janela de <guilabel
|
||
|
>Configuração da Tarefa</guilabel
|
||
|
>. </para>
|
||
|
<para
|
||
|
>Uma sub-tarefa é qualquer nó da árvore de WBS que tenha uma tarefa como mãe.</para>
|
||
|
|
||
|
</sect1>
|
||
|
|
||
|
<sect1 id="resource">
|
||
|
<title
|
||
|
>Recurso</title>
|
||
|
<para
|
||
|
>Um recurso é um item necessário para terminar uma tarefa. Os recursos poderão ser pessoas, equipamentos, infra-estruturas, fundos ou algo que seja necessário para efectuar o trabalho de um projecto. Os recursos podem ter uma disponibilidade em tempo limitado (&ie; um empregado que trabalhe 8 horas por dia, 5 dias por semana). </para>
|
||
|
<para
|
||
|
>A disponibilidade está definida nos <link linkend="calendar"
|
||
|
>calendários</link
|
||
|
>. </para>
|
||
|
<para
|
||
|
>No &kplato;, os recursos podem ser pessoas (trabalho) ou máquinas/dispositivos (material). </para>
|
||
|
</sect1>
|
||
|
|
||
|
<sect1 id="calendar">
|
||
|
<title
|
||
|
>Calendários</title>
|
||
|
<para
|
||
|
>Um calendário define em que altura um <link linkend="resource"
|
||
|
>recurso</link
|
||
|
> está disponível. </para>
|
||
|
<para
|
||
|
>Os calendários podem tanto ser uma semana de trabalho normal como em horas de trabalho especiais que poderão ser definidas de forma individual para cada dia. Isto permite um controlo muito subtil sobre a disponibilidade dos recursos. </para>
|
||
|
<para
|
||
|
>Cada <link linkend="resource"
|
||
|
>recurso</link
|
||
|
> está normalmente associado a um calendário. </para>
|
||
|
<para
|
||
|
>No &kplato;, pode até usar os calendários hierárquicos. </para>
|
||
|
</sect1>
|
||
|
|
||
|
<sect1 id="milestone">
|
||
|
<title
|
||
|
>Marco ('Milestone')</title>
|
||
|
<para
|
||
|
>Um marco ou 'milestone' é um evento agendado que significa a finalização de um item de entrega importante ou um conjunto de itens relacionados (marcando normalmente o fim de um período). Um marco é uma actividade de duração zero e sem esforço &ie; não está trabalho associado a uma tarefa. É uma marca no plano de trabalho que significa que algum trabalho já foi terminado. </para>
|
||
|
<para
|
||
|
>Normalmente um marco é usado como marcação no projecto, para validar como é que o projecto está a progredir e validar de novo o trabalho. Os marcos são usados também como imagens de alto-nível para a gestão validar o progresso do projecto. Em muitos casos, existe uma decisão a tomar num marco. </para>
|
||
|
</sect1>
|
||
|
|
||
|
<sect1 id="critical-path">
|
||
|
<title
|
||
|
>Caminho crítico</title>
|
||
|
<para
|
||
|
>Um caminho é uma série de tarefas ligadas. Na gestão de projectos, o caminho crítico é a sequência de elementos terminais da rede do projecto com a duração global maior, que define o menor tempo para completar o projecto. </para>
|
||
|
<para
|
||
|
>A duração do caminho crítico determina a duração do projecto inteiro. Qualquer atraso num elemento terminal no caminho crítico cria impactos directos na data de finalização planeada do projecto (i.e., não há flutuações no caminho crítico). Por exemplo, se uma tarefa do caminho crítico atrasar um dia, o projecto inteiro irá atrasar um dia (a menos que outra tarefa do caminho crítico possa acelerar um dia). </para>
|
||
|
<para
|
||
|
>Um projecto poderá ter vários caminhos críticos em paralelo. Um caminho paralelo adicional através da rede com a duração total menor que a do caminho crítico também é conhecido por caminho sub-crítico. </para>
|
||
|
<para
|
||
|
>Originalmente, o método do caminho crítico considerava apenas as dependências lógicas entre os elementos terminais. Um conceito relacionado é a cadeia crítica, que adiciona as dependências de recursos. </para>
|
||
|
<para
|
||
|
>O método do caminho crítico foi inventado pela empresa DuPont. </para>
|
||
|
</sect1>
|
||
|
|
||
|
<sect1 id="scheduling">
|
||
|
<title
|
||
|
>Escalonamento</title>
|
||
|
<para
|
||
|
>A calendarização é o processo de criação de um calendário de projecto, com base nos dados de projecto como as <link linkend="task"
|
||
|
>tarefas</link
|
||
|
>, os <link linkend="resource"
|
||
|
>recursos</link
|
||
|
> e os <link linkend="calendar"
|
||
|
>calendários</link
|
||
|
>. O resultado pode ser visto num gráfico, como um <link linkend="gantt"
|
||
|
>diagrama de Gantt</link
|
||
|
>. O &kplato; pode também gerar relatórios para um projecto. </para>
|
||
|
<para
|
||
|
>Existem normalmente vários modos de calendarização, como o optimista, o esperado e o pessimista. Ao criar uma tarefa, a percentagem de estimativa adicional para a calendarização optimista e pessimista poderão ser definidas. Estas opções são então usadas para os vários modos de calendarização. </para>
|
||
|
<para
|
||
|
>Ao fazer o calendário de um projecto com o &kplato;, poderá optar entre a calendarização optimista, esperada e pessimista. </para>
|
||
|
</sect1>
|
||
|
|
||
|
</chapter>
|