Fase de Construção, Fase de Transição

 

Fase de Construção

          Nesta fase , começa o desenvolvimento físico do software, produção de códigos, testes alfa. O principal objetivo desta fase é a construção do sistema de software, com foco no desenvolvimento de componentes e outros recursos do sistema, também  é preciso esclarecer os requisitos restantes bem como gerenciar os recursos de controle de operações para otimizar custos, programações e qualidade.

Objetivos

• Minimizar custos de desenvolvimento, otimizar recursos e evitar retrabalho. A palavra chave é eficiência.
• Disponibilizar as versões úteis (alfa, beta e etc) com rapidez. Os testes ALFA são realizados durante a fase de Construção.
• Concluir a análise, o projeto, o desenvolvimento e o teste de todas as funcionalidades.
• Verificar e decidir se o software está pronto para implantação. 
• Atingir a qualidade adequada com rapidez e eficiência.

   

Artefatos

• O Sistema  - O próprio sistema executável, pronto para iniciar os testes beta.

• Plano de Implantação - guia a equipe de implantação e transição para eles disponibilizarem o software. Essa é apenas uma versão inicial do plano, as versões finais são feitas na Transição. Em projetos menores o Plano de Implantação pode estar embutido no Plano de Desenvolvimento de Software.

• Conjunto de Testes - Testes implementados e executados para validação e estabilidade das versões (releases)

• Modelo de Implementação - Expandido a partir daquele criado durante a fase de elaboração; todos os componentes criados no final da fase de construção.

• Materiais de Treinamento - Manuais do Usuário e outros materiais de treinamento. Rascunho preliminar, baseado em casos de uso.  Poderá ser necessário se o sistema tiver um forte aspecto de interface de usuário.

• Plano de Iteração - Plano de iteração para a fase de transição concluído e analisado.

• Modelo de Design - Atualizado com novos elementos de design identificados durante a conclusão de todos os requisitos.

• Caso de Desenvolvimento - Refinado com base na experiência inicial do projeto. O ambiente de desenvolvimento, incluindo o processo, as ferramentas e o suporte automatizado necessários para dar assistência à equipe de transição já estará posicionada.

• Ferramentas - As ferramentas usadas para dar suporte ao trabalho de Construção são instaladas.

• Modelo de Dados - Atualizado com todos os elementos necessários para suportar a implementação persistente (por exemplo, tabelas, índices, etc.).

Atividades Básicas

• Gerenciamento de recursos, otimização de controle e processo
• Desenvolvimento completo do componente e teste dos critérios de avaliação definidos
• Avaliação dos releases do produto de acordo com os critérios de aceitação para a visão

 

Marco: Capacidade Operacional Inicial 

      O marco Capacidade Operacional Inicial determina se o produto está pronto para ser implantado em um ambiente de teste beta.Quando chegamos aqui podemos nos perguntar se:

• Os modelos de Análise e Design estão estáveis?
• Resolvemos todos os problemas de design?
• Abordamos todos os casos de uso?
• Glossário e SAD estão atualizados?

Fase de Transição

 Nesta fase ocorre a entrega do software ao usuário. O objetivo desta fase é disponibilizar o sistema, tornando-o disponível e compreendido pelo usuário final. As atividades desta fase incluem o treinamento dos usuários finais e também a realização de testes da versão beta do sistema visando garantir que o mesmo possua o nível adequado de qualidade.

Objetivos

• Validar o novo sistema em confronto com as expectativas do usuário treinamento de usuários e equipe de manutenção
• Implantação do sistema
• Correção de erros, melhoria no desempenho e na usabilidade
• Avaliação das baselines de implantação tendo como base a visão completa e os critérios de aceitação para o produto
• Obtenção de auto-suportabilidade do usuário
• Obtenção do consentimento dos envolvidos de que as baselines de implantação estão completas
• Obtenção do consentimento dos envolvidos de que as baselines de implantação são consistentes com os critérios de avaliação da visão

 Artefatos
   

Artefatos Básicos (em ordem de importância)	Estado no marco
O Build do Produto	Concluído de acordo com os requisitos do produto. O produto final deve ser utilizável pelo consumidor.
Notas de Release	Concluídas.
Artefatos de Instalação	Concluídos.
Material de Treinamento	Concluído para assegurar que o cliente possa ser auto-suficiente na utilização e manutenção do produto.
Material de Suporte para o Usuário Final	Concluído para assegurar que o cliente possa ser auto-suficiente na utilização e manutenção do produto.

fonte:http://www.wthreex.com/rup/

Atividades básicas

• Executar planos de implantação
• Finalizar o material de suporte para o usuário final
• Testar o produto liberado no local do desenvolvimento
• Criar um release do produto
• Obter feedback do usuário
• Ajustar o produto com base em feedback
• Disponibilizar o produto para os usuários finais

Marco: Release do Produto

No fim na fase de transição está o quarto marco mais importante do projeto, o Marco do Release do Produto. Nesse momento, você decide se os objetivos foram atendidos, e se outro ciclo de desenvolvimento deve ser iniciado. Em alguns casos, esse marco pode coincidir com o fim da fase de iniciação do próximo ciclo. O Marco do Release do Produto é o resultado da conclusão com êxito de Atividade: Revisão da Aceitação do Projeto. Os critérios básicos de avaliação para a fase de transição envolvem as respostas para estas questões:

• O usuário está satisfeito?
• As despesas reais com recursos são aceitáveis se comparadas com as planejadas?

No Marco do Release do Produto, o produto está em produção e o ciclo de manutenção posterior ao release inicia. Isso pode envolver o início de um novo ciclo ou de algum release de manutenção adicional.

Fontes:

• http://infoblogs.com.br/view.action?contentId=40213&RUP-A-Importancia-dos-Marcos.html
  
• http://www.wthreex.com/rup/portugues/index.htm
• http://brunomarota.blogspot.com.br/2012/06/rup-para-concursos-parte-6-fase-de.html
• http://www.infoescola.com/engenharia-de-software/rup/
• http://tec4rup.wordpress.com/2010/05/13/rup-fases/

As fases do RUP - parte 1 (concepção e elaboração)

As fases do RUP

O ciclo de vida de software do RUP é dividido em quatro fases sequenciais  cada uma concluída por um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos principais. Em cada final de fase é executada uma avaliação para determinar se os objetivos da fase foram alcançados. Uma avaliação satisfatória permite que o projeto passe para a próxima fase.

Uma passagem pelas quatro fases é um ciclo de desenvolvimento. Cada passagem pelas quatro fases produz uma geração do software. A menos que o produto "desapareça", ele irá se desenvolver na próxima geração, repetindo a mesma seqüência de fases de iniciação, elaboração, construção e transição, mas agora com ênfase diferente nas diversas fases. Esses ciclos subsequentes são chamados de ciclos de evolução. À medida que o produto atravessa vários ciclos, são produzidas novas gerações.

Os ciclos de evolução podem ser disparados por melhorias sugeridas pelos usuários, mudanças no contexto do usuário, mudanças na tecnologia subjacente, reação à concorrência e assim por diante.

Vamos agora falar sobre as duas fases iniciais do RUP: As fases de Concepção e de Elaboração.

Fase de Concepção

Objetivos

A meta dominante da fase de iniciação é atingir o consenso entre todos os envolvidos sobre os objetivos do ciclo de vida do projeto. A fase de iniciação tem muita importância principalmente para os esforços dos desenvolvimentos novos, nos quais há muitos riscos de negócios e de requisitos que precisam ser tratados para que o projeto possa prosseguir.

Os objetivos principais da fase de iniciação incluem:

• Estabelecer o escopo do software do projeto e as condições limite, incluindo uma visão operacional, critérios de aceitação e o que deve ou não estar no produto;
•  Discriminar os casos de uso críticos do sistema, os principais cenários de operação e o que direcionará as principais trocas de design;
•  Exibir, e talvez demonstrar, pelo menos uma opção de arquitetura para alguns cenários básicos;
• Estimar o custo geral e a programação para o projeto inteiro;
• Estimar riscos em potencial (as origens de imprevistos);
• Preparar o ambiente de suporte para o projeto.

Atividades básicas

• Formular o escopo do projeto;
• Planejar e preparar um caso de negócio;
• Sintetizar uma possível arquitetura;
• Preparar o ambiente para o projeto.

Marco: Objetivos do Ciclo de Vida

O Marco de Objetivos do Ciclo de Vida avalia a viabilidade básica do projeto.

Fase de Elaboração

Objetivos

A meta da fase de elaboração é criar a baseline para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção. A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação de risco. A estabilidade da arquitetura é avaliada através de um ou mais protótipos de arquitetura.

Os objetivos primários da fase de elaboração incluem:

• Assegurar que a arquitetura, os requisitos e os planos sejam estáveis o suficiente e que os riscos sejam suficientemente diminuídos a fim de determinar com segurança o custo e a programação para a conclusão do desenvolvimento;
• Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto;
•  Estabelecer uma arquitetura da baseline derivada do tratamento dos cenários significativos do ponto de vista da arquitetura, que normalmente expõem os maiores riscos técnicos do projeto;
•   Produzir um protótipo evolutivo dos componentes de qualidade de produção, assim como um ou mais protótipos descartados para diminuir riscos específicos como:
•    Trocas de design/requisito;
•    Reutilização de componentes;
• Possibilidade de produção do produto ou demonstrações para investidores, clientes e usuários finais.
•  Demonstrar que a arquitetura de baseline suportará os requisitos do sistema a um custo justo e em tempo justo;
•  Estabelecer um ambiente de suporte;
•  Configurar o ambiente de suporte para o projeto. Isso inclui criar um caso de desenvolvimento, criar templates e diretrizes, e configurar ferramentas.

Atividades básicas      

•  Definir, validar e criar a baseline da arquitetura com rapidez e eficiência;
•  Refinar a Visão, com base nas informações novas obtidas durante a fase;
•  Criar planos de iteração detalhados e baselines para a fase de construção;
•  Refinar o caso de desenvolvimento e posicionar o ambiente de desenvolvimento;
• Refinar a arquitetura e selecionar componentes.

Marco: Arquitetura do Ciclo de Vida

O marco Arquitetura do Ciclo de Vida estabelece uma baseline gerenciada para a arquitetura do sistema e permite o escalonamento da equipe do projeto na fase de Construção.

RUP - Linhas Mestras - Uso de Software de Modelos Visuais, Verificação da qualidade do software, Gestão e Controle de Mudanças do Software

 Uso de Software de Modelos Visuais

Ao abstrair a programação do seu código e representá-la utilizando blocos de construção gráfica, o RUP consegue uma maneira efetiva de se ter uma visão geral de uma solução. O uso de modelos visuais também pode permitir que indíviduos de perfil menos técnico (como clientes) tenham um melhor entendimento de um dado problema, e assim se envolvam mais no projeto como um todo.

A línguagem de modelagem UML tornou-se um padrão industrial para representar projetos, e é amplamente utilizada pelo RUP.


Uso de Software de Modelos Visuais

Ao abstrair a programação do seu código e representá-la utilizando blocos de construção gráfica, o RUP consegue uma maneira efetiva de se ter uma visão geral de uma solução. O uso de modelos visuais também pode permitir que indíviduos de perfil menos técnico (como clientes) tenham um melhor entendimento de um dado problema, e assim se envolvam mais no projeto como um todo.

A línguagem de modelagem UML tornou-se um padrão industrial para representar projetos, e é amplamente utilizada pelo RUP.

Verificação da Qualidade do Software

Não assegurar a qualidade do software é a falha mais comum em todos os projetos de sistemas computacionais. Normalmente pensa-se em qualidade de software após o término dos projetos, ou a qualidade é responsabilidade de uma equipe diferente da equipe de desenvolvimento. O RUP visa auxiliar no controle do planejamento da qualidade, verificando-a na construção de todo o processo e envolvendo todos os membros da equipe de desenvolvimento.


Gestão e Controle de Mudanças do Software

Em todos os projectos de software a mudança é inevitável. O RUP define métodos para controlar e monitorizar mudanças. Como uma pequena mudança pode afetar aplicações de formas inteiramente imprevisiveis, o controle de mudanças é essencial para o sucesso de um projeto.

O RUP também define áreas de trabalho seguras, garantindo a um programador que as mudanças efetuadas noutro sistema não afetarão o seu sistema.


Fonte:
http://www.guiafar.com.br/portal/index.php/pt/artigos/tecnologia-da-informacao/108-rup

RUP - Linhas Mestras - Gestão de Requisitos e Arquitetura de Componentes

Gestão de Requisitos 

Tem como característica sua eficácia em manter as sentenças dos claras dos requisitos, junto com os atributos aplicáveis. 

A coleta dos requisitos precisá ser uma tarefa que consiga coletar os dados principais sem falhas e ambiguidades. Seus principais  problemas acontecem na coleta de  tais dados pois:

- Nem todavia a fonte é confiável dos dados que foram estabelecidos.

- O linguajar pode dificultar a compreensão do requisito.

- O numero de requisitos pode ser impossível controlar.

-Há várias partes interessadas, nos requisitos que precisam ser gerenciados pelos grupos de pessoas de diferentes funções

De forma que as habilidades que devem ser notadas e averiguadas para identificar uma forma de gerenciar as dificuldades que serão encontradas. Abaixo segue importantes habilidades

Analise do problema

Uma das partes mais interessante do sistema pois uma opinião incorreta pode vir a calhar em graves problemas para o desenvolvimento do sistema. É o momento em que sentamos com o cliente e fazemos uma analise dos que engloba o  problema. Durante a analise, são estabelecidos os problemas reais, as fronteiras do sistema. O que pode ser realizado baseando-se no contexto do grupo, habilidades e o problema. Após toda a analise e um caso de negócio feito, é preciso que exista o entendimento do retorno esperado sobre o investimento feito.

Noções Básicas dos envolvidos.

Para que existe uma compreensão melhor e um bom diálogo com cliente é preciso reconhecer o tipo de cliente que estamos lhe dando. Pois a forma correta para o dialogo e a metodologia que será utilizada deve ser baseada no contexto do cliente. Se por exemplo é uma pessoa da área de Informática, não teremos problemas na identificação dos requisitos e o nível do modelo de negócio. Mas se for um cliente que não tem muito conhecimento sobre a área, protótipos conceituais, entrevista, questionário. Ferramentas que possam ajudar nessa necessidade da retirada dos requisitos

Definição do sistema e escopo do projeto

Pegar os dados recolhidos e converter numa documentação, grau de cada requisito, detalhamento, esforço estimado, nível de risco. Pode incluir também protótipos iniciais geralmente relacionados aos requisitos importantes.O escopo do projeto deve ser priorizado somente os requisitos necessários com o prazo adequado sem a necessidade que tenha de incluir os 'Ovos de pascoa' . Gerenciando com o grupo cada tarefa que foi solicitada.

Arquitetura dos componentes

Os componentes são grupos com interfaces bem definidas e comportamentos que fornecem forte encapsulamento do conteúdo e são, portanto, substituíveis.

Características

Arquitetura

O RUP fornece uma maneira metódica e sistemática de projetar, desenvolver e validar uma arquitetura. Oferecemos templates para descrição da arquitetura, com os conceitos de várias visões arquiteturais, e para a captura de estilo de arquitetura, regras de design e restrições. A disciplina Análise e Design contém atividades específicas orientadas para identificar restrições arquiteturais e para elementos significativos na arquitetura, além de diretrizes sobre como fazer escolhas arquiteturais. O processo de gerenciamento mostra como o planejamento das iterações iniciais considera o design de uma arquitetura e a resolução dos principais riscos técnicos. Consulte a disciplina Gerenciamento de Projeto e todas as atividades associadas ao Papel: Arquiteto de Software para obter mais informações.

A arquitetura é importante por vários motivos:

Ela permite obter e manter controle intelectual do projeto, gerenciar sua complexidade e manter a integridade do sistema.

Um sistema complexo é mais que a soma de suas partes; mais que uma sucessão de pequenas decisões táticas independentes. Ele precisa ter uma estrutura unificadora e coerente para organizar essas partes de modo sistemático e fornecer regras precisas sobre como pode ser aumentado, sem que sua complexidade cresça além da compreensão humana.

A arquitetura determina os meios para se obter melhor comunicação e entendimento em todo o projeto, estabelecendo um conjunto de referências e um vocabulário comuns, com os quais se discutem questões de design.

Componentes

É software pode ser definido como um pedaço não-trivial de software, um módulo, um pacote ou um subsistema, sendo que todos desempenham uma função clara, possuem uma fronteira clara e podem ser integrados em uma arquitetura bem definida. É a realização física de uma abstração do design.

Os componentes vêm de diferentes lugares:

Ao definir uma arquitetura muito modular, você identifica, isola, projeta, desenvolve e testa componentes bem formados. Esses componentes podem ser testados individualmente e gradualmente integrados para formar o sistema inteiro.

Introdução ao RUP

O RUP, abreviação de Rational Unified Process (ou Processo Unificado Rational), é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nome IRUP que agora é uma abreviação de IBM Rational Unified Process e tornando-se uma brand na área de Software, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade no processo de desenvolvimento.

O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação. Utiliza técnicas e práticas aprovadas comercialmente.

É um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos, porém o fato de ser amplamente customizável torna possível que seja adaptado para projetos de qualquer escala. Para a gerência do projeto, o RUP provê uma solução disciplinada de como assinalar tarefas e responsabilidades dentro de uma organização de desenvolvimento de software.

O RUP é, por si só, um produto de software. É modular e automatizado, e toda a sua metodologia é apoiada por diversas ferramentas de desenvolvimento integradas e vendidas pela IBM através de seus "Rational Suites".

Métodos concorrentes no campo da engenharia de software incluem o "Cleanroom" (considerado pesado) e os Métodos Ágeis (leves) como a Programação Extrema (XP-Extreme Programming), Scrum, FDD e outros.

Fonte:
http://pt.wikipedia.org/wiki/IBM_Rational_Unified_Process#Modelagem_visual_de_software

As três últimas áreas do conhecimento do PMBOK

As últimas três áreas do conhecimento do PMBOK que trataremos são: Comunicações, riscos e aquisições.

Gerenciamento das Comunicações

  Área que Identifica os processos relativos à geração, coleta, disseminação, armazenamento e destinação final das informações do projeto de forma oportuna e apropriada. Este área inclui:

· Identificar as partes interessadas;

· Planejar as comunicações - determinação das necessidades de informação e comunicação dos stakeholders: que necessidades, qual informação, quando será necessária e como lhes será dada;

· Distribuir informações - disponibilização das informações necessárias dos stakeholders do projeto na forma adequada;

· Gerenciar as expectativas das partes interessadas - geração, reunião e disseminação da informação para formalizar as expectativas dos interessados;

· Relatar desempenho - coleção e disseminação de informação de desempenho. Isto inclui relatório de situação, medição de progresso e previsões;

Gerenciamento dos Riscos

Área que possui os processos envolvidos na identificação, análise e controle dos riscos do projeto. Esta área inclui:

· Planejar o gerenciamento de riscos - determinação dos riscos que provavelmente afetarão o projeto e documentação das características de cada um;

· Identificar riscos - determinação dos riscos que provavelmente afetarão o projeto e documentação das características de cada um;

· Realizar análise qualitativa de riscos - avaliação dos riscos e das interações entre eles para estimar o rol de possibilidades de resultados do projeto;

· Realizar análise quantitativa de riscos - definição das etapas para maximizar oportunidades e eliminar ameaças;

· Planejar respostas aos riscos - resposta às alterações de riscos internos durante o desenvolvimento do projeto;

· Monitorar e controlar riscos.

Gerenciamento das Aquisições

Área do conhecimento que descreve os processos envolvidos na compra ou aquisição de produtos, serviços ou resultados para o projeto. Esta área inclui:

· Planejar aquisições - determinação do que e quando adquirir;

· Conduzir aquisições - documentação dos requisitos de produto e identificação das potenciais fontes;

· Administrar aquisições - obtenção da cotação, contrato, ofertas ou propostas, quando apropriados;

· Encerrar aquisições - encerramento e liquidação do contrato, inclui a resolução de todos os itens abertos (pendentes).

Até a próxima!!!

PMBOK - Áreas do Conhecimento - Gerência de Tempo

O objetivo da gerência do tempo de projeto é descrever os processos requeridos para o término do projeto, garantindo que o mesmo cumpra com os prazos definidos em um cronograma de atividades.

Os principais processos desta gestão são: as Definições, Seqüenciamento, Estimativa de Recurso e Estimativa de Duração das Atividades e o Desenvolvimento e Controle do Cronograma destas Atividades.

Definições das Atividades: identificação das atividades específicas do cronograma que necessitam ser executadas para produzir os diversos tangíveis do projeto;

Seqüenciar Atividades: identificação e documentação das dependências entre as atividades do cronograma;

Estimativa de Recursos de Atividade: estimativa do tipo e das quantidades dos recursos requeridos para executar cada atividade do cronograma;

Estimativa de Duração de Atividade: estimativa do período que será necessário para conclusão individual de cada atividade do cronograma;

Desenvolvimento do Cronograma: análise das sequências das atividades, suas dependências, durações e recursos requeridos para criar o cronograma;

Controle do Cronograma: controle das alterações efetuadas no cronograma;

A gerência do tempo de projeto e a gerência do custo do projeto são as áreas de maior exigência dentro de um projeto, pois são as mais vísiveis em sua gestão.

Algumas das ferramentas clássicas de Gestão de Tempo de Projeto são o PERT/CPM e o Diagrama de Gantt.

Figura 1 - Project Time management overview

Fonte:
PMBOK - A Guide to the Project Management Body of Knowledge -  Fourth Edition

PMBOK - Áreas de Conhecimento - Gerência de Escopo

Escopo, em gerenciamento de projetos, é a soma total de todos os produtos do projeto e seus requisitos ou características, e possui dois usos distintos: Escopo do Projeto e Escopo do Produto.

Escopo do projeto é "o trabalho que precisa ser realizado para entregar um produto, serviço ou resultado com as características e funções especificadas."

Escopo do produto são "as características e funções que caracterizam o produto, serviço ou resultado."

É importante observar que o Escopo do Projeto está mais orientado ao esforço (os como) enquanto o Escopo do Produto é mais orientado para os requisitos funcionais (os o quês).

Se os requisitos não forem completamente definidos e descritos e se não houver o controle de mudanças efetivo em um projeto, pode-se resultar no aumento do escopo ou da exigência.

A Gerência de Escopo visa garantir que o projeto realize todo e somente o trabalho necessário para o seu sucesso bem como garantir que o projeto realize todo e somente o trabalho necessário para o seu sucesso. 

Esta Gerência possui alguns processos tais quais representados na figura abaixo: 

Figura 1 - Project Scope Management: Inputs, Tools & Techniques, and Outputs

• Coletar Requisitos

Este processo faz parte do grupo de processos de planejamento e tem como objetivo principal descrever como a equipe irá executar os demais processos do gerenciamento de escopo. É importante salientar que, apesar do plano de gerenciamento do projeto (processo do gerenciamento de integração) definir o método do projeto como um todo, a definição do método do gerenciamento de escopo é feita dentro do processo de planejamento do escopo. Esta definição depende da área de atuação do projeto, por exemplo: um projeto da indústria automobilística deve se preocupar em realizar plantas do carro, maquetes, etc., já um projeto de software deverá conter casos de uso, protótipos, etc.

Figura 2 - Collect Requirements Data Flow Diagram

• Definir Escopo 

Este processo também faz parte do grupo de planejamento e busca detalhar o escopo do projeto a partir da declaração de escopo preliminar. Necessidades, desejos e expectativas de todas as partes interessadas, e não apenas dos patrocinadores, são analisados e convertidos em requisitos. O nível de detalhe da declaração do escopo do projeto pode determinar a eficácia com que a equipe de gerenciamento de projetos poderá controlar o escopo global do projeto. Entre os tópicos que compõem a declaração de escopo detalhada, encontram-se: objetivos do projeto, descrição do escopo do produto, requisitos do projeto, limites, entregas, critérios de aceitação, restrições, premissas, riscos iniciais e especificações do projeto.

Figura 3 - Define Scope Data Flow Diagram

• Criar EAP (WBS) 

Um dos instrumentos mais famoso na construção de um projeto é a EAP. A estrutura analítica do projeto, como é conhecida em português (WBS – work breakdown structure, in english), é uma decomposição hierárquica orientada à entrega (produto) do trabalho a ser executado para atingir os objetivos do projeto. Esta estrutura deve ser tão detalhada quanto for necessária para identificar um pacote de trabalho, ou seja, identificar uma entrega que possa ser mensurada em termos de custo e cronograma de forma que seja fácil gerenciar. É importante determinar até que nível será detalhada a EAP pois, assim como a decomposição excessiva pode levar a um esforço grande de gerenciamento, a não decomposição pode dificultar a definição de custos e prazos.

Figura 4 - Create WBS Data Flow Diagram

Veja que o objetivo de uma EAP é organizar o escopo para se definir as atividades a serem executadas, porém as atividades não fazem parte da EAP, uma vez que a mesma, como dito anteriormente, é orientada a entrega. Existe uma discussão onde se prega que um projeto deva ter várias EAPs, cada uma focada em uma determinada visão (cliente, desenvolvedores, patrocinadores, etc). Estas várias formas de representar a EAP ajudam, apesar do trabalho, a alinhar as expectativas e melhorar o gerenciamento por parte do líder do projeto. Este é um assunto bastante polêmico e proponho que falemos dele mais adiante. Por enquanto vamos seguir com os nossos processos da área de gerenciamento de escopo.

Figura 5 - Sample Work Breakdown Structure with Some

Branches Decomposed Down Through Work Packages

• Verificar Escopo

Processo responsável por obter a aceitação formal das entregas pelas partes interessadas. É importante salientar que este processo não trata do atendimento aos requisitos de qualidade, uma vez que isso será realizado por outro processo. No âmbito do gerenciamento de escopo, o conceito de entrega difere do conceito de produto. Enquanto aquela representa o resultado de uma ou mais atividades que compõe um pacote de trabalho, este representa algo com valor para o cliente final. Os conceitos só se sobrepõem quando a entrega do pacote de trabalho é o produto final do projeto.

Figura  6 - Verify Scope Data Flow Diagram

• Controlar Escopo

Último, porém não menos importante processo área de gerenciamento do escopo, o controle do escopo faz parte do controle integrado de mudanças, já discutido nos processos do gerenciamento integrado. Este processo é responsável por identificar se a mudança no escopo é realmente válida e importante para o projeto. Este processo garante, também, que todas as solicitações e ações corretivas recomendadas sejam processadas pelo controle integrado de mudanças.

Figura 7 - Control Scope Data Flow Diagram

Apenas como curiosidade, as mudanças não controladas são frequentemente chamadas de scope creep, ou seja, perda de controle do escopo, ou, como traduz o PMBOK, aumento do escopo do projeto.

Material utilizado como base para o Post: 

http://pt.wikipedia.org/wiki/Escopo_(gerenciamento_de_projeto)

http://tiinteligente.blogspot.com.br/2010/08/pmbok-areas-de-conhecimento_16.html

PMBOK - A Guide to the Project Management Body of Knowledge -  Fourth Edition

PMBOK -- Gerência de Custos, Qualidade e Recursos Humanos do Projeto

Gerência de Custos

Engloba uma serie de processos que visam garantir que o projeto seja executado e termine dentro do orçamento em que foi aprovado. Os processos executados nesta etapa são:

Planejamento de recursos: Determina quais, quando e quantos recursos (pessoas, equipamentos, material, etc) serão necessários para realizar as atividades do projeto.

Estimativa de custos: Consiste em estimar os custos dos recursos necessários para que as atividades do projeto sejam implementadas

Orçamento de custos: É alcançado distribuindo-se o orçamento total disponível para o projeto às suas atividades

Controle de custos: Monitora o progresso do projeto e atualiza o seu orçamento e gerenciando as mudanças feitas na linha de base dos custos.

http://tiinteligente.blogspot.com.br/2010/09/pmbok-areas-de-conhecimento.html

www.cin.ufpe.br/~if717/slides/pmbok-custos.pdf

http://www.slideshare.net/renneralves/gerenciamento-de-custos-em-projetos

Gerenciamento de Qualidade

Inclui todas as atividades que determinam as políticas de qualidade, de modo que o projeto atenda às necessidades que motivaram sua realização.

Planejamento da qualidade: identificação dos padrões de qualidade relevantes para o projeto e determinação de como satisfazê-los;

Garantia da qualidade: aplicação das atividades de qualidade planejadas e sistemáticas para garantir que o projeto emprega todos os processos necessários para atender aos requisitos;

Controle da qualidade: monitoramento de resultados específicos do projeto a fim de determinar se eles estão de acordo com os padrões relevantes de qualidade e identificação de maneiras de eliminar as causas de um desempenho insatisfatório.

http://pt.wikipedia.org/wiki/Gerenciamento_da_qualidade_do_projeto#Gerenciamento_da_Qualidade_do_Projeto

http://falandoemprojetos.wordpress.com/2010/04/21/entendendo-os-processos-de-qualidade-do-pmbok/

Gerenciamento Recursos Humanos

Processos necessários para melhor utilização das pessoas envolvidas no projeto

Planejamento Organizacional: identificação e documentação de funções, responsabilidades e relações hierárquicas do projeto, além da criação do plano de gerenciamento de pessoal

Montagem da equipe: obtenção dos recursos humanos necessários para terminar o projeto

Desenvolvimento da equipe: desenvolver as habilidades individuais de membros da equipe para aprimorar o desempenho do projeto;

Gerenciar a equipe: acompanhamento do desempenho de membros da equipe, fornecimento de feedback, resolução de problemas e coordenação de mudanças para melhorar o desempenho do projeto.

http://www.slideshare.net/fernando.palma/gerenciamento-de-projetos-pmbok-cap9-rh

http://pmbokrecursoshumanos.blogspot.com.br/

PMBOK - Áreas de Conhecimento - Gerência de Integração

São nove as áreas de conhecimento que fazem parte do PMBOK, e ele está estruturado desta maneira devido ao foco distinto que cada uma delas possui, exigindo habilidades específicas do gerente de projetos. Em duas delas, o próprio PMI criou certificações profissionais focadas nestas habilidades, como o gerenciamento de risco e de tempo. Esta lógica também se aplica para as áreas de gerenciamento de escopo, custos, qualidade, recursos humanos, comunicações e aquisições. Mas há uma exceção: o gerenciamento de integração. Esta área de conhecimento não possui um foco específico em um determinado assunto, nem tampouco exige uma especialização por parte dos profissionais que executam seus processos.

Esta Gerência é constituída por 3 Processos que são por Natureza Integrativos e a proposta é Assegurar a coordenação do Projeto bem como equilibrar objetivos e alternativas para atingir expectativas:

• Desenvolvimento do Plano do Projeto (Processo de Planejamento)
• Execução do Plano de Projeto (Processo de Execução)
• Controle Integrado de Mudanças (Processo de Controle)

Cada um desses Processos Possui: Entradas, Ferramentas e Técnicas e Saídas.

• Desenvolvimento do Plano de Projeto: 
• Utiliza Saídas de Outros Processos.
• Agrega os resultados dos outros processos de planejamento construindo um documento consistente e coerente. 
• Este Documento Guia a Execução e Controla o Projeto

1. O Plano de Projeto: 
• Guia a Execução do Projeto
• Documenta premissas do Projeto
• Documenta Decisões de Planejamento
• Provê uma base para medida de Progresso
2. Entradas
• Outras saídas de Planejamento
• Informações Históricas
• Políticas Organizacionais: Gerência de Qualidade, Administração Pessoal, Controle Financeiro e etc. 
• Restrições
• Premissas
3. Ferramentas e Técnicas 
• Metodologia de Planejamento de Projeto
• Habilidades e conhecimentos das partes envolvidas
• Sistema de Informação de Gerência de Projetos
• Gerencia de Valor Agregado
4. Saídas
• Plano de Projeto
• Project Charter
• Estratégia de Gerência de Projetos
• Declarações de Escopo
• Estrutura Analítica de Projeto
• Estimativas de Custo, datas das Atividades
• Documentos base para medição de desempenho
• Principais marcos e datas previstas
• Mão de Obra Chave
• Plano de Gerência de Risco
• Planos Auxiliares de Gerenciamento
• Etc. 
• Detalhes de Suporte
• Saídas de outros processos não incluídas no plano de Projeto
• Informação ou documentação adicional
• Documentação Técnica
• Documentação sobre Padrões Relevantes

• Execução do Plano de Projeto: Nesse processo, o Produto do Projeto é criado. É na execução que a maior parte do orçamento será gasta e onde o desempenho é monitorado. A necessidade de ações corretivas pode ser detectada. 
1. Entradas:
• Plano de Projeto
• Detalhes de Suporte
• Políticas Organizacionais
• Ações Preventivas
• Ações Corretivas
2. Ferramentas e Técnicas
• Habilidades de Administração em geral
• Habilidades de Técnicas e conhecimento do Produto
• Sistema de Autorização de Trabalho
• Reuniões de Revisão de Status
• Sistema de Informação de Gerenciamento de Projetos
• Procedimentos Organizacionais
3. Saídas
• Resultados do Trabalho
• Requisições de Mudança
• Controle Integrado de Mudanças: O objetivo desse processo é Coordenar as mudanças através de todo o projeto. 
• Determina que uma mudança ocorreu e a gerencia
• Mantém a Integridade das medidas de desempenho
• Reflete as Mudanças no escopo do produto no escopo do projeto
• Coordenar as mudanças entre as áreas do Conhecimento

1. Entradas
• Plano de Projeto
• Relatórios de Desempenho
• Requisições de Mudanças
2. Ferramentas e Técnicas
• Sistema de controle de mudanças
• Gerência de Configuração
• Medidas de Desempenho 
• Planejamento adicional
• Sistema de Informação de gerenciamento de projetos
3. Saídas
• Atualizações no Plano de Projeto
• Ações Corretivas
• Lições Aprendidas

Tais Processos Descritos Acima sao necessário para assegurar que os diversos elementos do projeto sejam adequadamente coordenados. 

Material Utilizado como Base para o Post:

http://ogerente.com.br/rede/projetos/area-de-conhecimento-perdida
http://www.slideshare.net/mauricioastiazara/gerncia-de-integrao-14301000
http://gerenciamento-fsi.blogspot.com.br/

PMBOK - Áreas de Conhecimento

A partir de agora iremos introduzir alguns posts sobre as Áreas de Conhecimento do PMBOK, e pra contextualizar o assunto abaixo suas áreas do conhecimento, em alguns dos posts vc pôde conhecer um pouco do PMBOK e como já deve saber este é dividido em 9 áreas de Conhecimento onde você entenderá um pouco a partir de agora:


O PMBOK é organizado em áreas de conhecimento, onde cada uma destas áreas é descrita através de processos. Cada área de conhecimento se refere a um aspecto a ser considerado dentro da gerência de projetos. A não execução de processos de uma área afeta negativamente o projeto, pois o projeto é um esforço integrado.

Suas Áreas de Conhecimento são as seguintes:
Qualidade, Recursos Humanos, Escopo, Aquisições, Integração, Comunicações, Custo, Riscos e Tempo.

Agora que conhece as 9 Áreas você poderá ver através dos próximos posts detalhes sobre cada uma dessas Áreas de Conhecimento.