Rational Unified Process (RUP)

O RUP é um processo proprietário criado pela Rational Software Corporation, e posteriormente adquirido pela IBM, para gerenciar de maneira eficiente as diversas ações no processo de software, para isso o RUP adota três premissas básicas:

• Uso de iterações para evitar o impacto no projeto
• Gerenciamento de mudanças e
• Abordagens dos pontos de maior risco o mais cedo possível.

A estrutura do RUP é dividido em 4 fases e 8 disciplinas, como mostrado na figura abaixo.

Fig. 1: Esquema de Iterações

Sua distribuição apresenta duas dimensões bem definidas:

• Eixo X -Tempo: divisão do ciclo de vida em fases e iterações, mostra os aspectos do ciclo de vida do processo à medida que se desenvolve.

• Eixo Y - Componentes de processo: produção de um conjunto específico de artefatos (produtos) com atividades bem definidas.

Cada fase tem um conjunto bem definido de objetivos e pode conter uma ou mais iterações, são elas:

• Iniciação - entendimento da necessidade e visão do projeto,
• Elaboração - especificação e abordagem dos pontos de maior risco,
• Construção - desenvolvimento principal do sistema,
• Transição - ajustes, implantação e transferência de propriedade do sistema.

Agrupamento lógico dos elementos do processo (atividades, artefatos e papéis). Corresponde às disciplinas essenciais do processo.

• Modelagem do negócio - Descreve o negócio através de casos de uso de negócio.
• Requisitos - Narrativa da visão do sistema. Descrição das funções do sistema.
• Análise e Projeto - Descrição de como o sistema será realizado na etapa de implementação.
• Implementação - Produção do código que resultará em um sistema executável.
• Testes - Verificar a integração entre todos os componentes de software, identificar e corrigir erros de implementação.
• Gestão de projetos - Especifica um conjunto de princípios a aplicar na gestão de projetos a nível de alocação de recursos, planejamento, identificação e gestão de riscos, etc.
• Gestão de configuração e mudança - Controla as mudanças e mantém a integridade dos artefatos do projeto.
• Definição do ambiente - Cobre a infra-estrutura necessária para desenvolver um sistema (seleção de ferramentas, definição das regras de negócio, interface, testes, etc.).

Referência:

Conheça o Rational Unified Process (RUP) Disponível em:<http://www.linhadecodigo.com.br/artigo/79/conheca-o-rational-unified-process-rup.aspx> Acessado em 30 de Outubro de 2016.

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Figura 1

Risk reduction with the RUP phase plan Disponível em:<http://www.ibm.com/developerworks/rational/library/1826.html> Acessado em 30 de Outubro de 2016.

Processo de Software - Interação

No processo iterativo várias fases do sistema é desenvolvido de forma conjunta. Com o intuito de se adequar mais rapidamente a mudanças, o sistema é desenvolvido com a presença ativa do usuário. Alguns modelos fazem uso de iteração mais efetivamente, dos quais temos:

• Incremental

É identificado os serviços mais importantes e os menos importantes. Com a quantidade de incrementos definida, o sistema é desenvolvido com os serviços de maior prioridade sendo entregues primeiro. Portanto, o cliente tem acesso a funcionalidades do sistema antes mesmo deste ser finalizado.

Fig. 1: Modelo Incremental

• Desenvolvimento em Espiral

No modelo em espiral cada fase do processo é descrita como um loop. Cada loop está dividido em quatro setores: Definição de objetivos, Avaliação e redução de risco, Desenvolvimento e validação e Planejamento.

Fig. 2: Modelo espiral

Referências

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Figura 1

Modelos Incremental, Espiral e de Prototipação. Disponível em: <http://engenhariadesoftwareuesb.blogspot.com.br/2012/12/blog-post.html> Acessado em 30 de Outubro de 2016.

Figura 2

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Processo de Software - Modelos

Os modelos de software são descrições do processo de software, no qual possuem uma estrutura genérica. Embora não sejam respostas definitivas de processo são uteis para exemplificar abstrações diferentes no desenvolvimento de software. Sommerville (2007), discuti quatro destes modelos:

Modelo em cascata

Consiste do princípio que as etapas avançam  conforme sua aprovação. Portanto, a fase seguinte não deve ser iniciado antes que atual esteja terminada.

Fig. 1: Esquema de processo em cascata

Modelo Evolucionário

O desenvolvimento evolucionário baseia-se na proposta de mudança constante do projeto, expondo o resultado ao cliente e refinando as versões até que seja desenvolvido um sistema adequado.

Fig. 2: Esquema de Processo Evolucionário

Desenvolvimento Formal de Sistema

Nessa modelo é utilizado uma especificação formal matemática, onde a verificação dos componentes seguem uma argumentação matemática para demonstrar que os componentes atendem sua especificação.

Fig. 3: Desenvolvimento Formal

Desenvolvimento Orientado a Reuso

Nessa abordagem os componentes possuem uma característica de reutilização. O processo de software se concentra na integração desses componentes, ao contrario de desenvolver um sistema do zero.

Referências:

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Figuras 1,2 e 3:

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Processo de Software - Introdução

O processo de software é um conjunto de atividade que leva a produção de um produto de software. Não existe um processo ideal de desenvolvimento, mas sim várias abordagens diferentes que atendem necessidades especificas. Suas atividades principais se mantêm semelhantes:

• Especificação de Software.

A especificação de software é a fase do processo na qual é identificado os requisitos do sistema. Esta atividade é realizada juntamente com os stakeholders do sistema, problemas nessa fazem possuem um custo elevado de manutenção pois afetam todas as fases seguintes do processo.

• Projeto e Implementação.

Processo no qual é desenvolvido a aplicação propriamente dita. O projeto de software é uma descrição dos componentes do sistema, sendo eles: interface, algoritmo e arquitetura.

• Validação de Software.

A validação destina-se a verificar se o sistema estar em conformidade com o que foi prometido. A verificação ocorre em todo processo de software, desde a definição de requisitos até o desenvolvimento do sistema. Os testes são feitos em três etapas, sendo elas:

1. Teste de Componente – Os componentes são testados individualmente, eles podem ser entidades simples como classes ou grupos de entidades.
2. Teste de Sistema – Os componentes são testados quando integrados. É feito uma varredura para detectar erros de interação não prevista ou erros de interface.
3. Teste de Aceitação – O sistema é testado com os dados fornecidos pelo cliente. O teste exercita o sistema de maneira diferente e pode expor erros não identificados anteriormente.

• Evolução de Software.

A evolução de software trata do potencial de escalabilidade do sistema. Em um processo no qual o desenvolvimento e a manutenção se tornam cada vez mais irrelevante.

Processo de software deve ser aprimorado e padronizado conforme a cultura da empresa, não existe um processo ideal. A padronização e aprimoramento desses processos produzem uma serie de melhorias para a empresa, entre elas, o aprimoramento da comunicação e a redução do tempo de treinamento. Além disso o processo é um passo inicial para introdução de novos métodos de engenharia de software.

Referência:

SOMMERVILLE, Ian. Engenharia de Software. 8ª Edição. São Paulo: Addison-Wesley, 2007.

Os 47 Processos do Guia do PMBok 5ª Edição

Após ter sido apresentados às mudanças ocorridas no do Guia PMBOK 5a edição, iremos agora analisar sucintamente o que acontece em cada processo. 

INTEGRAÇÃO

4.1 Desenvolver Termo de Abertura

      • Processo de desenvolver o documento que formalmente autoriza o projeto ou fase.

4.2 Desenvolver Plano de Gerenciamento do Projeto

     •Processo de documentar as ações necessárias para definir, preparar, integrar e coordenar todos os planos auxiliares.

4.3 Dirigir e Gerenciar a Execução

     • Processo de executar o trabalho definido no Plano de Gerenciamento do Projeto.

4.4 Monitorar e Controlar o Trabalho

     • Processo de monitorar e controlar o progresso do projeto de acordo com o Plano.

4.5 Realizar Controle Integrado de Mudanças

     • Processo de revisar, aprovar e controlar solicitações de mudança, bem como manter atualizados os documentos do projeto.

4.6 Encerrar Projeto ou Fase

     • Processo de finalizar todas as atividades e encerrar formalmente o projeto ou fase.

ESCOPO

5.1 Planejar Gerenciamento do Escopo

     •Processo de planejar como o escopo será definido, validado e controlado.

5.2 Coletar Requisitos

  • Processo de definir e documentar os requisitos necessários para atender necessidades e expectativas de interessados.

5.3 Definir Escopo

     • Processo de desenvolver uma descrição detalhada do projeto e do produto.

5.4 Criar EAP – Estrutura Analítica do Projeto

     • Estrutura Analítica do Projeto é uma subdivisão hierárquica orientada a entregas. Criar a EAP envolve definir as entregas principais e seus componentes, bem como todo o trabalho do projeto.

5.5 Validar Escopo

     • Processo de formalizar a aceitação das entregas do projeto.

5.6 Controlar Escopo

     • Processo de monitorar e controlar o escopo do projeto.

TEMPO

6.1 Planejar Gerenciamento do Tempo

     • Processo planejar como será definido, gerenciado e controlado o cronograma do projeto.

6.2 Definir Atividades

     • Processo de identificar atividades específicas que precisam ser realizadas para produzir as entregas do projeto.

6.3 Definir Sequência de Atividades

     • Processo de identificar e documentar dependências entre as atividades do cronograma.

6.4 Estimar Recursos das Atividades

     • Processo de estimar tipo e das quantidades de recursos necessários para realizar cada atividade do cronograma.

6.5 Estimar Durações das Atividades

     • Processo de estimar o número de períodos de trabalho necessários para realização das tarefas.

6.6 Desenvolver Cronograma

     • Processo de analisar os recursos necessários, restrições do cronograma, durações e sequências de atividades para criar o cronograma do projeto

6.7 Controlar Cronograma

     • Processo de monitorar e controlar o progresso do projeto e a performance de execução do cronograma, tomando medidas corretivas quando necessário.

CUSTO

7.1 Planejar Gerenciamento dos Custos

     • Processo planejar como será definido, gerenciado e controlado o orçamento do projeto.

7.2 Estimar Custos

     • Processo de estimar os custos dos recursos necessários para a execução das atividades.

7.3 Determinar Orçamento

     • Processo de agregar custos estimados de atividades individuais ou pacotes de trabalho para determinar o orçamento do projeto.

7.4 Controlar Custos

     • Processo de monitorar e controlar o progresso do projeto e a performance de execução do orçamento, tomando medidas corretivas quando necessário.

QUALIDADE

8.1 Planejar Gerenciamento da Qualidade

     • Processo de identificar padrões, normas ou requisitos de qualidade do projeto e produto, e documentar como o projeto demonstrará concordância.

8.2 Realizar Garantia de Qualidade

     • Processo de auditar requisitos de qualidade e os resultados das medições de controle de qualidade para assegurar que os padrões apropriados de qualidade estão sendo observados.

8.3 Controlar Qualidade

     • Processo de monitorar e controlar os resultados e as atividades do Plano de Gerenciamento da Qualidade.

RECURSOS HUMANOS

9.1 Planejar Gerenciamento de Recursos Humanos do Projeto

     • Processo de identificar e documentar funções, responsabilidades e habilidades requeridas para a criação do Plano de Gerenciamento de Recursos Humanos

9.2 Mobilizar Equipe do Projeto

     • Processo para confirmar a disponibilidade dos recursos humanos e obter a equipe necessária para terminar o projeto.

9.3 Desenvolver Equipe do Projeto

     • Processo de integração e construção da equipe do projeto, bem como melhoria de competências individuais e coletivas da equipe.

9.4 Gerir Equipe do Projeto

     • Processo de acompanhar desempenho de membros da equipe, fornecendo feedback e solucionando conflitos.

COMUNICAÇÃO

10.1 Planejar Comunicação

     • Processo de determinar as necessidades de informações das partes interessadas no projeto para definir abordagens adequadas de comunicação.

10.2 Distribuir Informação

     • Processo de tornar disponíveis as informações necessárias aos interessados.

10.2 Relatar Desempenho

     • Processo de coleta e distribuição das informações sobre o desempenho e performance do projeto.

RISCOS

11.1 Planejar Gerenciamento dos Riscos

     • Processo de definir como serão identificados, analisados e gerenciados os riscos do projeto, incluindo procedimentos e padrão para gestão de riscos.

11.2 Identificar Riscos

     • Processo de determinar quais riscos podem afetar o projeto e documentar suas características.

11.3 Realizar Análise Qualitativa

     • Processo de priorização dos riscos por meio da avaliação subjetiva das suas probabilidades de ocorrência e impactos no projeto.

11.4 Realizar Análise Quantitativa

     • Processo de análise numérica do efeito dos riscos identificados sobre os objetivos gerais do projeto.

11.5 Planejar Respostas aos Riscos

     • Processo de desenvolver estratégias e ações para ampliar oportunidades e reduzir ameaças aos objetivos do projeto.

11.6 Monitorar e Controlar Respostas aos Riscos

   • Processo de monitorar os riscos, implementando as ações do plano de resposta quando necessário.

AQUISIÇÕES

12.1 Planejar Gerenciamento das Aquisições

     • Processo de documentar as decisões de aquisição do projeto, definir tipos de contratos e identificar potenciais fornecedores.

12.2 Conduzir Aquisições

     • Processo de obter propostas de fornecedores, selecionar fornecedor e formalizar contrato.

12.3 Administrar Aquisições

     • Processo de gerenciar as relações contratuais, fiscalizar e monitorar o desempenho dos contratos.

12.4 Encerrar Aquisições

     • Processo de finalizar formalmente todas as aquisições e contratos do projeto.

STAKEHOLDERS

13.1 Identificar Stakeholders

     • Processo de identificar pessoas, grupos ou organizações que poderiam afetar ou serem afetadas pelo projeto.

13.2 Planejar Gerenciamento dos Stakeholders

     • Processo de desenvolver estratégias para engajar efetivamente os stakeholders ao longo do projeto.

13.3 Gerenciar Engajamento dos Stakeholders

     • Processo de gerenciar expectativas e promover o engajamento dos stakeholders em favor do projeto.

     13.4 Controlar Engajamento dos Stakeholders

• Processo de monitorar os relacionamentos com stakeholders do projeto.

Fonte: NÃO TENHA PRESSA – 47 PROCESSOS DO GUIA PMBOK 5 EDIÇÃO

Os 47 Processos do Guia PMBOK 5ª Edição

Após ter apresentado a importância do planejamento à luz do Guia PMBOK 5a edição, iremos agora apresentar os novos 47 processos do Guia PMBOK 5a edição.

Primeiramente, cumpre ressaltar que não houve mudança nos Grupos de Processos, que continuam sendo:

• Iniciação
• Planejamento
• Execução
• Monitoramento e Controle
• Encerramento

Figura 1 – Grupos de Processos

Dentre as novidades, em relação aos processos, houve a criação da nova área do conhecimento chamada Stakeholders ou Partes Interessadas. Na versão anterior, Guia PMBOK 4a edição, existiam 42 processos. Nesta nova edição, temos 47 processos. Foram adicionados os seguintes processos:

• Planejar Gerenciamento do Escopo
• Planejar Gerenciamento do Tempo
• Planejar Gerenciamento do Custo
• Planejar Gerenciamento dos Stakeholders
• Controlar Stakeholders

Vale ressaltar que o Guia PMBOK 5a edição já está disponível em inglês, mas ainda não existe a tradução oficial para português. Logo, os nomes dos processos foram traduzidos por mim, tradução livre e não oficial.

Além dos cinco novos processos, alguns processos foram renomeados: 5.5; 8.3; 10.2; 10.3 e 12.3. Os processos 13.1 e 13.3 pertenciam à área do conhecimento Comunicação e foram transferidos para a nova área Stakeholders. A seguir, temos os processos do Guia PMBOK 5a edição.

Figura 2 – Processos do Guia PMBOK 5a edição

Figura 3 – Processos do Guia PMBOK 5a edição

Fonte: Processos do PMBok 5ª Edição - Blog MundoPM 

Planejamento do Projeto com o PMBok

Ainda existem muitas pessoas questionam a importância do planejamento, acreditando que planejar é perda de tempo. Penso que o grande problema reside na dificuldade que muitos de nós temos em lidar com as incertezas de maneira estruturada.

É mais fácil iniciar rapidamente a execução do que parar, pensar e investir tempo pesquisando possibilidades, fazendo estimativas e planejando soluções para diferentes cenários. Afinal, se iniciar a execução sem um planejamento prévio, mesmo resultando em desperdício e retrabalho, podemos alegar que “não sabíamos” ou “não havíamos pensado nessa possibilidade”.

Em síntese, planejar é prevenir (ou tentar prevenir) o sofrimento futuro. Esse custo do planejamento (investir tempo, recursos e esforço para planejar) é uma conta que sempre teremos que pagar. Você tem a opção de pagar agora ou pagar depois, eventualmente com juros e multas (retrabalho, desperdício e perdas).

Figura 1 – Pay me now, or pay me later.

Assim como em outros investimentos, em planejamento queremos obter a melhor relação custo-benefício. Essa relação custo-benefício, na construção de um prédio por exemplo, envolve o fluxo de receitas e despesas. Isto é, se eu tirar R$10milhões do bolso e investir à vista, pagando tudo adiantado, na construção de um prédio que irá demorar 2 anos para depois começar a vender suas salas comerciais, pode ser um mal negócio. Se eu conseguir começar a vender as salas antes da construção, terei um fluxo de receitas ao longo da construção, que poderei casar com o fluxo de despesas financiadas ou parceladas ao longo da obra. Trata-se de uma alternativa bem mais interessante, certo?

A mesma coisa é com o planejamento. Você pode passar 2 anos planejando detalhadamente o projeto de um produto complexo, como um novo concorrente do iPad, por exemplo. Depois disso, você poderia iniciar a execução, com duração aproximada de mais 2 ou 3 anos. Finalmente, depois de 5 anos, você provavelmente vai lançar um produto obsoleto no mercado, certo? Por outro lado, é possível adequar o esforço de planejamento à execução em um processo contínuo, mais ágil e flexível, utilizando protótipos e outras estratégias para chegar antes ao mercado.

Figura 2 – Abordagem Waterfall (cascata)

Neste sentido, o Capítulo 3 reformulado nesta nova edição do Guia PMBOK (5a edição) modifica o foco dos projetos e de seu planejamento, desmistificando a tão criticada abordagem waterfall. Os processos e melhores práticas do Guia PMBOK, bem como seus grupos de processos, não pregam o engessamento e burocratização em gerenciamento de projetos, muito pelo contrário. Na verdade, a implementação das melhores práticas do PMI pode e deve ser customizada e modificada para se adaptar ao ambiente e ao contexto dos projetos, atendendo às particularidades de cada organização.

Figura 3 – Abordagem Incremental (TRENTIM, 2013)

Figura 4 – Abordagem Ágil (TRENTIM, 2013)

O PMI reforça ainda mais a importância de que os projetos produzam valor de negócio. Criar ou agregar valor é o objetivo final de todo projeto. Caso contrário, se não houver justificativa e benefícios adequados, os projetos não tem sentido. Ou seja, fazendo uma análise crítica, quantas organizações sabem realmente fazer projetos? Quantos dos projetos da sua organização nunca deveriam ter sido iniciados…

Portanto, todo projeto deve:

• Criar e agregar valor de negócio;
• Demonstrar claramente os benefícios que serão realizados;
• Oferecer flexibilidade na sua implementação; e
• Permitir agilidade na execução das tarefas.

Isto é, existem três níveis em que poderíamos dividir as atividades dentro de um projeto. Eu imaginei esses níveis em concordância com a abordagem Strategic Project Leadership:

• Nível estratégico do projeto
  • Definir objetivos, podem ser qualitativos, que norteiam a abordagem de gerenciamento do projeto, considerando, por exemplo, as dimensões do Modelo Diamante – NCTP (Shenhar e Dvir, 2007)
  • Estratégia consiste em definir regras e diretrizes para a tomada de decisão, de modo a resultar em ações consistentes e coerentes na direção do objetivo traçado
• Nível tático do projeto
  • Desenvolver e manter o plano de gerenciamento do projeto atualizado, buscando efetividade (eficácia + eficiência)
  • Desdobrar a estratégia em pacotes menores de fácil implementação e gerenciamento
• Nível operacional do projeto
  • Organizar o dia-a-dia das atividades, gerenciar recursos e liderar a equipe, bem como a gestão de stakeholders
  • Prover informações de monitoramento e controle para o nível tático, permitindo a atualização dos planos

Figura 5 – Processos do Guia PMBOK 5a edição

Fonte: Blog MundoPM - A Importância do Planejamento