gerenciamento de projetos de ti unidade iv

59

GERENCIAMENTO DE PROJETOS DE TI

Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

Unidade IV

5

10

15

20

5 GESTÃO DA QUALIDADE EM TI

Entregar serviços de TI com qualidade é uma tarefa extremamente importante, porém muito difícil, logo é um desafio de qualquer CEO. Diante destes desafios, muitas empresas utilizam processos de gestão da qualidade como ISO 9001, CMMI, Cobit, ISO 10006, ISO 9001, entre outros, com o objetivo de satisfazer aos seus clientes.

A utilização de processos para gestão da qualidade inicialmente pode parecer complicada e onerar a operação, mas a sua maturidade torna a gestão mais simples.

De forma a padronizar a gestão da qualidade muitas organizações criaram normas técnicas que estabelecem os procedimentos e melhores práticas para atingir a gestão de qualidade, como a famosa ISO 9000.

5.1 Controle da qualidade

Controle da qualidade é um processo pelo qual é realizada a revisão de todos os fatores envolvidos na produção com ênfase em três aspectos:

• elementos como controles, gerenciamento de tarefas, processos definidos e bem gerenciados, desempenho e critérios de integridade e identificação de registros;

• competência, tais como conhecimento, habilidades, experiência e qualificações;

60

Unidade IV

Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

• elementos de software, tais como a integridade pessoal, confiança, cultura organizacional, motivação, espírito de equipe e os relacionamentos de qualidade.

Para melhor controlar a qualidade, diversas metodologias e normas foram criadas conforme veremos adiante.

5.1.1 NBR ISO 9001: Sistema de Gestão da Qualidade

A NBR ISO 9001 é a norma brasileira baseada na norma internacional ISO 9001 que define os requisitos necessários para o sistema de gestão da qualidade, conhecido como SQC, em uma organização. Desta forma, o principal objetivo da norma é prover a confiança de que o provedor poderá fornecer de forma consistente e repetitiva, bens e serviços de acordo com o que o cliente especificou.

A norma atualmente é utilizada em todo o setor, desde pequenas a grandes empresas, e cada dia é mais comum o uso de termos como qualidade, auditoria, processos, requisitos, especificações, conformidades e não conformidades.

A norma ISO é baseada no PDCA, que significa: Plan (Planejar), Do (Fazer), Check (Verificar), Act (Agir), criando um ciclo contínuo, conforme demonstrado na figura abaixo:

Plan

Check

Act DoISO

Figura 30: PDCA

5

10

15

61


Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

É importante clarificar que a norma não define requisitos sobre a gestão empresarial, ou seja, não define quais devem ser as características de seu produto ou como o mesmo deve ser produzido. São apresentadas exigências para gerenciar os requisitos do cliente e garantir que os mesmos sejam atendidos de forma eficaz.

Um exemplo básico de aplicação da ISO seria criar um processo de envio e recebimento de computadores para um laboratório. Imagine que a empresa XPTO é responsável pela manutenção de computadores da marca Xingling. Assim, sempre que um computador é levado por um cliente, a empresa registra os dados do equipamento e do cliente e envia para seu próprio laboratório a fim de identificar o problema. Uma vez identificado o problema, a empresa, então, pode solucioná-lo, enviar para a fábrica para solução ou mesmo registrar como sem solução.

As tarefas descritas acima serão realizadas inúmeras vezes pela empresa, assim é importante que todos os funcionários a executem da mesma forma para garantir a consistência e repetitividade. Desde modo, a empresa deveria documentar este processo e compartilhar com seus funcionários para garantir que todos o conhecem.

A documentação e o compartilhamento dos processos não garantem que os funcionários o conhecem e o seguem, assim é necessário executar auditorias. Elas podem ser comparadas a uma prova, onde o auditor vai verificar se o funcionário conhece os processos e os utiliza de forma correta.

A ideia do PDCA é garantir a melhoria constante do processo, pois inicialmente o processo é planejado, executado e verificado se pode tomar ações corretivas para melhorá-lo, caso necessário.

Um dos pontos mais criticados na norma ISO 9001 e em outras é que elas aumentam em muito a burocracia, pois exigem

5

10

15

20

25

30

62

Unidade IV

Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

procedimentos, maior controle de documentos e registros, manuais, reuniões auditorias, etc. Isto tudo tende a aumentar os custos de produção de bens ou serviços, por isso muitos veem a norma como uma forma de aumentar os custos internos da empresa.

É bem verdade que se a norma não for implantada corretamente ela pode prejudicar a empresa aumentando os custos internos, porém se a implantação acontecer com coerência e os processos forem melhorados continuamente a ISO aumenta a qualidade de entrega por um custo aceitável.

Melhoria contínua do sistema de gestão

da qualidade

Cliente

Requisitos

Satisfação

Cliente

Responsabilidade da gestão

Gestão de recursos

Realização do produto (e/ou serviço)

Input Output Produto Serviço

Sistema de gestão da qualidade

Medição, análise, melhoria

Figura 31: Sistema de gestão da qualidade.

Fonte: <http://3.bp.blogspot.com/_-cxMcw9Ds9w/Sx9Bzgl7WQI/AAAAAAAAALE/svumc7JFKcc/s1600-h/sgq.bmp>.

A norma possui basicamente oito princípios conforme abaixo:

1. foco no cliente;

2. liderança entre objetivos comuns;

3. envolvimento de todos;

5

10

15

63


Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

4. abordagem de processos;

5. considerar o impacto de decisões em outros processos;

6. melhoria contínua;

7. decisão baseada em dados;

8. benefícios mútuos entre clientes e fornecedores.

A norma ISO 9001 faz parte de uma família de normas ISO 9000, conforme explicado abaixo:

• ISO 9000:1987: foi a primeira norma que tinha como base a norma britânica BS 5750, sendo subdividida em três modelos:

— ISO 9001:1987 Modelo de garantia da qualidade para preto, desenvolvimento, produção, montagem e prestadores de serviço – aplicava-se a organizações cujas atividades eram voltadas à criação de novos produtos.

— ISO 9002:1987 Modelo de garantia da qualidade para produção, montagem e prestação de serviço – compreendia essencialmente o mesmo material da anterior, sem abranger a criação de novos produtos.

— ISO 9003:1987 Modelo de garantia da qualidade para inspeção final e teste – abrangia apenas a inspeção final do produto e não se preocupava como o produto era feito.

• ISO 9000:1994: Apresentava os termos e definições da norma ISO 9001:1994.

• ISO 9001:1994: Enfatizava a qualidade através de ações preventivas ao invés da validação apenas no produto final.

5

10

15

20

25

64

Unidade IV

Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

• ISO 9001:2000: Combina os três padrões 9001, 9002, e 9003 em um único.

• ISO 9000:2005: Sistema de Gestão da Qualidade, Fundamentos e Vocabulário.

• ISO 9001:2008: Sistema de Gestão da Qualidade, Requisitos.

• ISO 9004:2009: Sistema de Gestão da Qualidade, Diretrizes para Melhoria de Desempenho.

Um dos pontos mais importantes é sem dúvida a certificação. Assim, para uma empresa receber o certificado ISSO deve passar pela auditoria de uma empresa externa, que irá avaliar os processos internos da empresa com a finalidade de comprovar que todos são seguidos de forma correta.

5.1.2 NBR ISO 10006: Gestão da Qualidade – Diretrizes para a qualidade no gerenciamento de projetos

A NBR ISO 10006:2000 é um padrão escrito pela ISO com diretrizes de qualidade para o gerenciamento de projeto. Define como os princípios e práticas da gestão de qualidade relacionam-se com o gerenciamento de projetos.

A norma pode ser aplicada a projetos de complexidade variada, ou seja, desde projetos pequenos a grandes, pequena ou longa duração, independente do tipo de produto ou serviço. Os seguintes processos fazem parte da norma:

• processo estratégico;

• processos de gerenciamento de interdependências;

• processos relacionados ao escopo;

• processos relacionados ao tempo;

• processos relacionados ao custo;

5

10

15

20

25

65


Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

• processos relacionados aos recursos;

• processos relacionados ao pessoal;

• processos relacionados à comunicação;

• processos relacionados ao risco;

• processos relacionados aos suprimentos.

DICA: Uma boa fonte de leitura para comparação entre a norma ISO e o PMBOOK poder ser acessada em: <http://www.pmimg.org.br/artigos/Combinando10006EPMBOK.pdf>.

5.1.3 Maturidade em desenvolvimento de software – CMMI

CMMI, Capability Maturity Model Integration, é um modelo, um conjunto de práticas de gerenciamento e de melhoria de qualidade a ser aplicado no processo de desenvolvimento de software.

Foi criado em 1987 por Watts Humphrey, na Universidade de Carnegie Mellon, ligada ao Software Engineer Instute (SEI), com a finalidade de garantir maturidade na capacidade de desenvolvimento de software. O CMMI é uma evolução do CMM, também conhecido como software CMM ou SW-CMM.

A versão atual do CMMI 1.2 apresenta três modelos:

• CMMI for Development (CMMI-DEV) publicada em agosto de 2006: dirige-se ao processo de desenvolvimento de produtos e serviços;

• CMMI for Acquisition (CMMI-ACQ) publicada em novembro de 2007: dirige-se aos processos de aquisição e terceirização de bens e serviços;

• CMMI for Services (CMMI-SVC) publicada em fevereiro de 2009: dirige-se aos processos de empresas prestadoras de serviços.

5

10

15

20

25

66

Unidade IV

Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

O modelo CMMI permite a representação da maturidade no desenvolvimento de software através de cinco níveis, conforme a figura abaixo:

1

2

3

4

5 Otimização

Gerenciando

Definido

Repetível

Inicial

Processo aperfeiçoado continuamente

Processo previsível e controlado

Processo consistente e padronizado

Processo disciplinado

Processo imprevisível e sem controle

Figura 32: Níveis de maturidade CMMI

1. Inicial: neste nível, os processos são improvisados e geralmente não são seguidos. Estimativas são realizadas sem nenhum planejamento. Compromissos de prazos e custos não são cumpridos. Procedimentos e conhecimentos pertencem às pessoas e não ao projeto.

2. Repetível: aqui, as políticas e os procedimentos para gerenciar o desenvolvimento de software estão definidos e são obedecidos. O planejamento é baseado em estimativas e na experiência anterior de outros projetos. Os projetos utilizam processos definidos, usados, disseminados, documentados, medidos e fiscalizados com rotinas de melhoria. Processos afetados são apenas os gerenciais.

3. Definido: os processos utilizados são estabelecidos e padronizados em toda a organização. Processos técnicos

5

10

15

67


Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

passam a ser considerados ao lado dos processos gerenciais.

4. Gerenciado: nesta fase são estabelecidas metas quantitativas para os processos e produtos, medidas de qualidade e produtividade são coletadas em todos os projetos. A gestão é realizada com base em informações quantitativas.

5. Otimizado: nesta fase a organização utiliza a melhoria contínua do processo identificando pontos fracos e defeitos através de ações preventivas.

5.1.4 Governança em TI

Nos dias atuais, todas as organizações fazem uso da Tecnologia da Informação para trabalhar os dados operacionais e prover informações gerenciais aos executivos da organização. A criação e a operação de uma infraestrutura de TI exigem um alto investimento pela organização e o gerenciamento deste ambiente nem sempre é fácil, podendo levar a organização ao fracasso. Para ajudar este cenário surgiu a Governança de TI, uma subdisciplina da Governança Corporativa focada no departamento do TI, em sua performance e no gerenciamento de risco.

O grande interesse pela Governança em TI surgiu principalmente pelas iniciativas de conformidade como a Sarbanes Oxley, nos Estados Unidos, e a Basel II, na Europa, e também por perceber que os projetos de TI podem facilmente sair de controle e afetar profundamente as organizações.

De forma geral, a Governança Corporativa tem o objetivo de recuperar e garantir a confiabilidade em uma determinada empresa para os seus acionistas. Suas principais características são:

• participação;

• estado de direito;

5

10

15

20

25

68

Unidade IV

Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

• transparência;

• responsabilidade;

• orientação por consenso;

• igualdade e inclusividade;

• efetividade e eficiência;

• suporte à auditoria.

Para suportar as implementações da Governança em TI existem alguns frameworks, conforme abaixo:

• Control Objectives for Information and related Technology (Cobit);

• IT Infrastructure Library (ITIL);

• ISO/IEC 27001 (ISO 27001);

• IT Baseline Protection Catalogs;

• Information Security Management Maturity Model ISM3;

• AS8015-2005 Australian Standard for Corporate Governance of Information and Communication Technology;

• ISO/IEC 38500:2008 Corporate governance of information technology

5.1.5 CobiT

CobiT significa Control Objectives for Information and related Technology, que é um guia, formulado como framework para gestão de TI, recomendado pelo ISACF (Information Systems Audit and Control Foundation, <www.isaca.org>).

Foi publicado em 1996 com foco no controle e análise de sistemas da informação. Em sua segunda edição, em 1998, foi

5

10

15

20

25

69


Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

adicionado um guia prático de implementação e execução. A versão atual 4.1 pode ser obtida no próprio site da ISACA e introduziu as recomendações de gerenciamento de ambiente de TI dentro do modelo de governança.

O CobiT é orientado ao negócio, fornece informações para gerenciar os processos alinhados aos objetivos de negócios, ajuda a otimizar os investimentos de TI e fornece métricas para avaliação dos resultados.

Tem como objetivo auxiliar três audiências distintas:

1. gerentes que precisam avaliar o risco e controlar os investimentos em TI;

2. usuários que precisam ter garantias de que seus serviços de TI são bem gerenciados;

3. auditores que podem se apoiar nas recomendações Cobit para avaliar o nível de gestão e aconselhar o controle interno.

O CobiT é organizado em quatro domínios de conhecimento, conforme demonstrado na figura abaixo:

5

10

15

70

Unidade IV

Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

Objetivos de negócios

Monitoração

Entrega e suporte

Planejamento e organização

Governança em TI

CobiT

Aquisição e implementação

• Efetividade• Eficiência• Confidencialidade• Integridade• Disponibilidade• Fidelidade• Confiabilidade

• Pessoas• Sistemas de aplicação• Tecnologia• Infraestrutura• Dados

Informação

Recursos de TI

Figura 33: Domínio do CobiT

De acordo com o professor Eduardo (Fagundes), as características de cada domínio são:

• Planejamento e organização:

— define o plano estratégico de TI;

71


Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

— define a arquitetura da informação;

— determina a direção tecnológica;

— define a organização de TI e seus relacionamentos;

— gerencia os investimentos de TI;

— gerencia a comunicação das direções de TI;

— gerencia os recursos humanos;

— assegura o alinhamento de TI com os requerimentos externos;

— avalia os riscos;

— gerencia os projetos;

— gerencia a qualidade.

• Aquisição e implementação:

— identifica as soluções de automação;

— adquire e mantém os softwares;

— adquire e mantém a infraestrutura tecnológica;

— desenvolve e mantém os procedimentos;

— instala e certifica softwares;

— gerencia as mudanças.

• Entrega e suporte:

— define e mantém os acordos de níveis de serviços (SLA);

— gerencia os serviços de terceiros;

— gerencia a performance e capacidade do ambiente;

— assegura a continuidade dos serviços;

— assegura a segurança dos serviços;— identifica e aloca custos;

5

10

15

20

25

72

Unidade IV

Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

— treina os usuários;

— aconselha e assiste aos usuários;

— gerencia a configuração;

— gerencia os problemas e incidentes;

— gerencia os dados;

— gerencia a infraestrutura;

— gerencia as operações.

• Monitoração:

— monitora os processos;

— analisa a adequação dos controles internos;

— provê auditorias independentes;

— provê segurança independente.

O principal benefício do CobiT para as organizações é possibilitar a compreensão de seu desempenho e medir o seu progresso. Da mesma forma como a maturidade é avaliada no CMMI, o CobiT também utiliza um modelo semelhante, que pode ser classificado em:

0. inexistente;

1. inicial / ad hoc;

2. repetitivo, mas intuitivo;

3. processos definidos;

4. processos gerenciáveis e medidos;

5. processo otimizados.

5

10

15

20

73


Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

Desta forma, é possível avaliar onde a organização está hoje e aonde pretende chegar, traçando assim os planos para atingir seus objetivos.

6 ATUAL PARADIGMA DE GESTÃO DE PROCESSO DE DESENVOLVIMENTO

6.1 O que é um processo de desenvolvimento de software?

O processo de desenvolvimento de software e/ou sistema consiste basicamente em um conjunto de atividades ordenadas com a finalidade de obter um produto final, que pode ser um software ou um sistema. Geralmente o processo de desenvolvimento de software é estudado dentro da área de engenharia de software, pois é considerado um dos principais elementos para obter qualidade no produto final e cumprir corretamente prazo, custos e funcionalidades conforme contratado.

Diante disso, podemos citar que o principal objetivo de um processo de desenvolvimento de software é garantir a qualidade do produto desenvolvido conseguindo uma boa produtividade.

O processo possui diversos componentes que ajudam a responder as questões: Quem, O que?, Como?, Por quê?, Quando? (Who?, What ?, How?, Why?, When?). Os principais componentes são: papéis, artefatos, atividades, técnicas, práticas e ferramentas.

De forma geral, o processo de desenvolvimento de software pode ser dividido em fases:

• planejamento, definição de requisitos, construção de protótipos;

• construção do sistema (inclui codificação e testes);

• implantação (colocar em produção, treinar usuários).

5

10

15

20

25

74

Unidade IV

Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

Atualmente, existem diversos modelos e frameworks que podem ser utilizados para o desenvolvimento de software, conforme segue:

• ágil;

• cleanroom;

• iterativo;

• RAD;

• RUP;

• espiral;

• cascata;

• XP;

• Scrum.

Cada um destes modelos utiliza um processo para o desenvolvimento de software. Basicamente podemos citar três modelos: cascata, interativo e ágeis.

No modelo cascata, os desenvolvedores seguem os passos em ordem, estabelecem os requisitos, analisam, projetam, implantam e mantém. Muitas vezes, o resultado final não atende a necessidade do cliente, pois após o planejamento atividades serão executadas até o final sem reavaliação.

No método interativo, os passos são revistos em todas as atividades, assim é o método preferido, pois a cada interação, os requisitos podem ser alterados. É muito comum um cliente pedir uma coisa e no meio do caminho reavaliar e mudar os requerimentos.

Os métodos ágeis parecem ser melhores que os antigos, pois usam menos tempo dos programadores. Geralmente suas fases são extremamente pequenas, não durando mais que 1 mês, como é o caso do Scrum ou XP.

5

10

15

20

25

75


Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

6.2 IBM Rational Unified Process

RUP é um processo proprietário de desenvolvimento de software criado pela Rational Software Corporation, adquirida pela IBM, que ficou conhecido como IRUP.

Utiliza a abordagem da orientação a objetos em sua concepção e é projetado e documentando utilizando a linguagem UML. É um processo considerado pesado e preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos.

O RUP toma como premissa seis práticas de engenharia de software. São elas:

• desenvolvimento interativo;

• gerenciamento de requisitos;

• arquitetura baseada em componentes;

• modelagem utilizando a UML como ferramenta;

• melhoria contínua de processos e produtos de software;

• configuração e gerenciamento de mudança.

De forma geral, o modelo RUP faz uso de três entidades, que são os trabalhadores (papéis), as atividades e os artefatos. Através da utilização de fluxogramas é possível relacionar as atividades e os papéis em sequências para a produção do resultado.

Como este modelo se baseia no modelo incremental e interativo, busca resolver os problemas clássicos do desenvolvimento de software que são: mudança de requisitos, falta de gerência de riscos, estouro de prazos, falta de produtividade e de documentação e atualização de documentos.

5

10

15

20

25

76

Unidade IV

Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

O RUP é dividido em quatro fases distintas:

1. concepção: ênfase no escopo do sistema;

2. elaboração: ênfase na arquitetura;

3. construção: ênfase no desenvolvimento;

4. transição: ênfase na implantação.

Phases

Iterations

Workflows

Business modeling

Analysis & Design

ImplementationTest

Deployment

Configuration & Change Mgmt

Project managementEnviroyment

Requeriments

Inception Elaboration Construction Transition

Initial Elab #1

Elab #2

Const #1

Const #2

Const #N

Tran #1

Tran #2

Figura 34: Processo RUP

Como pode ser visto na figura acima, cada etapa do projeto (Business Modelling, Requirements, etc.) passa-se pelas quatro fases do RUP: concepção, elaboração, construção e transição. Desta forma, podemos assegurar que todas as etapas serão revistas em cada uma das fases facilitando assim o gerenciamento do projeto.

6.3 SCRUM

Scrum é um framework para desenvolvimento ágil e gerenciamento de projetos, inicialmente concebido para o

5

10

77


Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

gerenciamento de projetos em empresas de fabricação de automóveis por Takeuchi e Nonaka através do artigo The New Product Development Game (Takeuchi; Nonaka, 1986).

Takeuchi e Nonaka notaram que utilizando equipes pequenas e multidisciplinares produziam melhores resultados, e associaram estas equipes à formação Scrum do rugby.

Em 1993, Jeff Sutherland, John Scumniotales e Jeff McKenna conceberam, documentaram e implementaram o Scrum na empresa Easel. Mais tarde, em 1995, o Scrum foi implementado por Ken Schwaber para o desenvolvimento de software.

De forma simplificada, o Scrum possui os seguintes componentes:

• Product Backlog: são as funcionalidades de um produto requeridas pelas pessoas envolvidas no projeto, como: usuários, clientes, executivos, desenvolvedores e outras pessoas do time;

• Product Owner: representa o usuário e o cliente, e tem o objetivo de verificar se as funcionalidades exigidas estão no projeto;

• Scrum Master: sua função é garantir que o projeto está caminhando de forma correta e que cada indivíduo do time tem a ferramenta necessária para desempenhar sua função. Tem a função ainda de agendar reunião, verificar andamento dos trabalhos, etc. Este indivíduo é essencialmente um gerente de projetos;

• Developers: são os indivíduos responsáveis pelo desenvolvimento do produto;

• Testers: são os indivíduos responsáveis pelo teste do produto de acordo com as funcionalidades exigidas para cada versão;

5

10

15

20

25

30

78

Unidade IV

Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

• Customers: são os clientes que estão pagando pelo produto;

• Subject Matter Especialist: especialistas em determinadas áreas que podem avaliar o tempo necessário para cada tarefa;

• Sprints: são Milestones de curta duração (Milestone é um marco dentro do projeto);

• Bugs: são problemas que aparecem durante o desenvolvimento do produto;

• Daily Scrum: reuniões diárias de curta duração para avaliar o andamento do projeto.

O processo do Scrum começa com a criação do product backlog, onde todas as funcionalidades necessárias do produto são identificadas. Em seguida, é criado um release backlog, com todas as funcionalidades que deverão ser implementadas neste release (versão).

Uma vez criado o release backlog, o time prioriza as funcionalidades e identifica o esforço necessário para cada atividade através do uso de, no mínimo, 2 ou 3 especialistas, de forma a obter o tempo necessário para desenvolver esta versão.

Agora é necessário dividir as atividades do release backlog em sprints de forma que suas atividades tenham duração entre 3 e 30 dias. É importante lembrar que quanto menor for o ciclo de criação de novas versões, menor será o tempo dos sprints. Ao término de cada sprint deve ser possível testá-lo e validar o seu funcionamento, assim, caso haja algum problema é fácil identificar os atrasos no projeto.

Nota-se então que é imprescindível monitorar o progresso de cada sprint para ter um controle adequado do projeto, e para

5

10

15

20

25

30

79


Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

isso pode-se utilizar gráficos burndown que mostram o trabalho efetuado pelo tempo, conforme a figura abaixo:

4500

4000

3500

3000

2500

2000

1500

1000

500

01 2 3 4 5 6 7 8 9 10 11 12 13 1415 16 17 18 19 20

Trabalho

Figura 35: Gráfico Burndown (trabalho x tempo)

É necessário ainda que o Scrum Master organize reuniões diárias de aproximadamente 15 minutos para verificar como as tarefas estão sendo executadas e quais são os problemas e/ou bugs encontrados. Em geral, as seguintes perguntas devem ser realizadas nesta reunião:

• O que vocês fizeram ontem?

• O que vocês estão fazendo hoje?

• Quais são os problemas?

• Que ferramentas vocês precisam?

• Que obstáculos estão em seu caminho?

Diante do que foi exposto é possível avaliar que o Scrum é muito útil no desenvolvimento de software por ser ágil e tratar os problemas de forma rápida, objetivando a entrega. Um ponto principal é identificar quais funcionalidades serão desenvolvidas em cada release, a fim de criar ciclos curtos de desenvolvimento.

5

10

15

80

Unidade IV

Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

A figura abaixo demonstra de forma simples o processo Scrum:

Reunião de scrum diária

Product backlog

Sprint backlog

24 horas

2-4 semanas

Incremento no produto

Figura 36: Processo Scrum

6.4 Estratégias para o sucesso em projetos

Para um bom gerenciamento de projetos é necessário combinar o conhecimento contido tanto no PMBOK quanto na ISO 10006. É fácil perceber que existem muitos pontos semelhantes, porém há também muitas diferenças. Em geral, a combinação deles pode dar suporte para uma gestão eficiente de projetos.

A estratégia que as organizações deveriam seguir para implementar a ISO 10006 é:

1. reavaliar e entender as informações do PMBOK;

2. reavaliar e entender as informações da ISO 10006;

3. desenvolver um processo ou metodologia para o gerenciamento de processos desde seu início até seu encerramento;

4. o processo deve ser adaptável para permitir o uso em projetos de tamanhos diversos, não engessando as pessoas que estão trabalhando;

5

10

15

81


Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

5. criar processos para os elementos-chaves dentro de um processo, de forma que todos os projetos sigam o mesmo direcionamento, como: gerenciamento de mudança e de riscos, alocação de recursos, etc.;

6. criar padrões de qualidade de forma a garantir que os resultados originais foram obtidos, as partes interessadas estão satisfeitas e que os recursos do projeto são bem gerenciados;

7. Auditar os projetos de forma a garantir que os processos estão sendo utilizados e que a qualidade é observada;

8. Garantir que os projetos tenham um processo de encerramento e que a lições aprendidas sejam divulgadas e armazenadas de forma correta para que erros e/ou problemas não sejam repetidos novamente.

7 CONCLUSÃO

Diante do que foi exposto nesta apostila, pode-se observar o quanto é importante o gerenciamento de projetos para uma organização. Existem diversas ferramentas, metodologias e frameworks para ajudar na gestão, porém é fundamental que os gerentes de projeto façam o controle adequado dos requisitos e da gestão de risco.

Pode-se observar que em todo projeto o passo mais importante é compreender o que o cliente realmente quer e garantir que a entrega final esteja de acordo com o solicitado. Sabemos que muitas vezes o próprio cliente não sabe exatamente o que deseja como resultado final. Assim, cabe ao fornecedor do serviço identificar as possibilidades e demonstrá-las para que o cliente faça a escolha.

Devemos utilizar as informações recebidas aqui para evitar a todo custo que a figura abaixo aconteça em um projeto.

5

10

15

20

25

82

Unidade IV

Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

Figura 37: Modelo de entrega padrão de serviços ao cliente

ANEXO

Sarbanes-Oxley

É uma lei americana assinada em 30 de julho de 2002, pelos senadores Paul Sarbanes (Democrata de Maryland) e Michael Oxley (Republicano de Ohio), que busca garantir a criação de mecanismos de auditoria e segurança confiáveis nas empresas. Inclui regras para a criação de comitês e comissões encarregadas de supervisionar suas atividades e operações, de modo a mitigar riscos aos negócios, evitar a ocorrência de fraudes ou ter meios de identificar quando elas ocorrem, garantindo a transparência na gestão das empresas.

A lei, conhecida pelo nome SOX ou Public Company Accounting Reform and Investor Protection Act foi motivada por escândalos financeiros coorporativos, dentre eles o da Enron, que acabou por afetar drasticamente a empresa de auditoria Arthur Andersen.

5

10

83


Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

Basel II

É o segundo acordo da família Basel, que são recomendações sobre leis e regulamentações bancárias feitas pelo Basel Committee on Banking Supervision na Europa. O objetivo do acordo, primeiramente publicado em junho de 2004, é criar padrões internacionais que os reguladores bancários podem usar ao criar regras sobre quanto capital os bancos precisam possuir para se proteger de operações financeiras de risco.

UML

UML ou Unified Modeling Language é uma linguagem de modelagem não proprietária, que permite aos desenvolvedores visualizarem o produto de seus trabalhos através de diagramas padronizados. Um exemplo de UML pode ser visto na figura abaixo:

{creditHistory( )=”low”}

{If Order.Client.creditHistory( )=“low” Them Order.paidshould be TRUE}

purchasereport

OrderReceive Datepaid: Booleannumber: Stringprice: Currency

send ( )close ( )

Clientnameaddress

creditHistory( ): String

IndividualClientcreditCardNumber

CorporateClientcontactNamecreditHistorycreditLimit

remind ( )monthBill (Integer)

Employee

Enventory

OrderStringquality: Integerprice: Currencysatisfied: Boolean

Product

* 1

1

*

0.1

1

Figura 38: UML

5

10

84

Unidade IV

Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

Scrum do Rugby

De acordo com o site brasileiro Rugby Mania (), o Scrum do rugby é o seguinte:

“Acontece na disputa pela bola em casos de penalidades ou faltas. É normalmente formado por 3 linhas de jogadores, sendo 3 na primeira, 4 na segunda e 1 na terceira, totalizando 8 jogadores. A bola é jogada no meio do “túnel” do Scrum pelo Half Scrum do time lesado pela penalidade pela esquerda do seu time. Neste momento, um time tenta empurrar o outro até a bola sair entre as pernas dos jogadores e continuar o jogo. A bola não pode sair pelo túnel e a formação não pode cair nem girar mais de 90º sob pena de ter de repetir o Scrum ou inclusive inverter a posse da bola a critério do juiz.”

Índice de figuras

Figura 1: Triângulo do projeto ........................................................... 4Figura 2: Standish Group Report ..................................................... 7Figura 3: Ciclo de vida de um projeto ............................................ 9Figura 4: Modelo básico gerenciamento projeto .....................18Figura 5: Exemplo de gráfico PERT ................................................22Figura 6: CPM .........................................................................................24Figura 7: Tela principal Project ........................................................25Figura 8: Detalhes tabela de tarefas .............................................26Figura 9: Informações do projeto ..................................................27Figura 10: Tarefas no Microsoft Project ......................................28Figura 11: Gráfico com relacionamento entre atividades ....29Figura 12: Criando um milestone ..................................................29Figura 13: Projeto com fase piloto e de implantação ...........30Figura 14: Gráfico com detalhes das atividades do projeto ................................................................................................30Figura 15: Definindo milestone no Project ................................31Figura 16: Avaliação de trabalho das atividades .....................31Figura 17: Assinalando recursos .....................................................32

5

10

85


Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

Figura 18: Custo do recurso .............................................................33Figura 19: Exemplo de relatório gráfico ......................................34Figura 20: Visualização através de calendário ..........................35Figura 21: Visualização de tarefas e gráfico Gantt .................35Figura 22: Visualização pelo diagrama de rede ........................36Figura 23: Visualização de alocação de recursos .....................36Figura 24: Visualização de custos dos recursos ........................37Figura 25: Processo gerenciamento de riscos ...........................42Figura 26: Dias de alocação de recurso 1 ...................................46Figura 27: Dias de alocação de recurso 2 ...................................47Figura 28: Ficha de controle de risco (página 1) .....................50Figura 29: Ficha de controle de risco (página 2) .....................51Figura 30: PDCA ....................................................................................59Figura 31: Sistema de gestão da qualidade. ..............................61Figura 32: Níveis de maturidade CMMI .......................................65Figura 33: Domínio do CobiT ...........................................................69Figura 34: Processo RUP ....................................................................75Figura 35: Gráfico Burndown (trabalho x tempo) ...................78Figura 36: Processo Scrum ................................................................79Figura 37: Modelo de entrega padrão de serviços ao cliente .................................................................................................81Figura 38: UML ......................................................................................83

Referências bibliográficas

Alencar, A. J.; Schimtz, E. A. Análise de Risco em Gerência de Projetos. 1. ed. Rio de Janeiro, Rio de Janeiro: Brasport, 2006.

Barbi, F. C. (s.d.). Os 7 passos do gerenciamento de projetos. Acesso em: 21 de 03 de 2010. Disponível em: MSDN: <http://www.microsoft.com/brasil/msdn/tecnologias/carreira/gerencprojetos.mspx>.

Barnes, J. (2007). Implementing the IBM Rational Unified Process and Solutions: A Guide to Improving Your

86

Unidade IV

Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

Software Development Capability and Maturity. IBM Press.

Calder, A.; Watkins, S. (2008). IT Governanace: A Manager’s Guide to Data Security and ISO27001/ISO 27002. 4. ed. Kogan.

Como Tudo Funciona. (s.d.). Burj Dubai, o edifício mais alto do mundo. Acesso em 14 de 03 de 2010, disponível em Como Tudo Funciona: <http://viagem.hsw.uol.com.br/burj-dubai.htm>.

Cooper, D., Grey, S., Raymond, G., & Walker, P. (2005). Project Risk Management Guidelines: Managing Risk in Large Projects and Complex Procurements. John Wiley & Sons.

Dinsmore, P. C., & Brewin, J. C. (2006). The AMA Handbook of Project Management (2 ed.). Amacom.

Fagundes, E. M. (s.d.). COBIT. Acesso em 20 de 03 de 2010, disponível em Efagundes.com: http://www.efagundes.com/Artigos/COBIT.htm

Gibbs, R. D. (2007). Project Management with the IBM Rational Unified Process: Lessons From The Trenches. IBM Press.

Hillson, D., & Simon, P. (2007). Practical Project Risk Management: The ATOM Methodology. Management Concepts.

ITGI. (s.d.). IT Givernance Institute. Acesso em 20 de 03 de 2010, disponível em <http://www.itgi.org/>.

Kerzner, H. (2009). Project Management: A Systems Approach to Planning, Scheduling, and Controlling (10 ed.). John Wiley & Sons.

87


Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

Microsoft. (s.d.). Um histórico rápido do gerenciamento de projeto. Acesso em 14 de 03 de 2010, disponível em Microsoft Office Project: <http://office.microsoft.com/pt-br/project/HA011353421046.aspx>.

Planner. (s.d.). Planner Gnome. Acesso em 21 de 03 de 2010, disponível em <live.gnome.org: http://live.gnome.org/Planner>.

PMI São Paulo. (s.d.). O Instituto. Acesso em 14 de 03 de 2010, disponível em Project Manager Institute – São Paulo, Brasil Chapter: <http://www.pmisp.org.br/instituto.asp>.

Portny, S. E. (2007). Project Management For Dummies (2 ed.). John Wiley & Sons.

Posições e Formações do Rugby . (s.d.). Acesso em 03 de 04 de 2010, disponível em Rugby Mania: <http://www.rugbymania.com.br/2009/rugby-posicoes08.asp>.

Project Control. (s.d.). Project Control. Acesso em 21 de 03 de 2010, disponível em <http://www.projectcontrol.com.br/>.

Project Management Institute. (2008). A Guide to the Project Management Body Of Knowledge (PMBOK® Guide) (4 ed.). Project Management Institute.

Takeuchi, H., & Nonaka, I. (1 de Janeiro de 1986). The New New Product Development Game. Harvard Business Review Article , p. 10.

The Standish Group. (s.d.). Acesso em 14 de 03 de 2010, disponível em <http://www.standishgroup.com/>.

Trac. (s.d.). Trac. Acesso em 21 de 03 de 2010, disponível em Trac: <http://trac.edgewall.org/>.

Vinci, L. d. Monalisa.

88

Unidade IV

Revi

são:

Ros

ani -

Dia

gram

ação

: Már

cio

- 09

/09/

10

Wiki. (s.d.). Frederick Winslow Taylor. Acesso em 14 de 03 de 2010, disponível em Wikipedia: <http://en.wikipedia.org/wiki/Frederick_W._Taylor>.

Wiki. (s.d.). Henry Gantt. Acesso em 14 de 03 de 2010, disponível em Wikipedia: <http://en.wikipedia.org/wiki/Henry_Gantt>.

Acrônimos

Acrônimo Significado Tradução

ERP Enterprise Resource Planning Sistemas de Gestão Empresarial

CRM Customer Relationship Management Gestão de Relacionamento com o Cliente

PM Project Manager Gerente de Projetos

PMI Project Management Institute Instituto de Gerenciamento de Projeto

PMP Project Management Professional Profissional de Gerenciamento de Projeto

PMBOK Project Management Body of Knowledge Corpo de Conhecimento sobre Gerenciamento de Projeto

CMMI Capability Maturity Model Integration

RUP Rational Unified Process Processo Racional Unificado

XP eXtreme Programming Programação Extrema

MSF Microsoft Solutions Framework Framework de Soluções Microsoft

WBS Work breakdown structure Estrutura Analítica de Trabalho

SOW Statement of Work Escopo de Trabalho

GANTT Gannt Graphical Gráficos de Gantt

PERT Program Evaluation and Review Technique Programa de Avaliação e Análise Técnica

CPM Critical Path Method Método de Caminho Crítico

CIO Cief Information Officer Diretor de TI

ISO International Organization for Standardization Organização Internacional para Padronização

BS British Stardardization Padronização Britânica

Cobit Control Objectives for Information and related Technology

Controle de Objetivos para a Informação e Tecnologia Associada

gerenciamento de projetos de ti unidade iv

Documents