Rodrigo Oliveira Spínola
[email protected] Doutor e Mestre em Engenharia de Software pela COPPE/UFRJ.Realizou seu Pós-Doutorado na University of Maryland Baltimore County e Centro Fraunhofer nos Estados Unidos.Atualmente é Professor Titular do Programa de Pós-Graduação em Sistemas e Computação da Universidade Salvador - UNIFACS.
Marco Antônio Pereira Araújo
[email protected] Doutor e Mestre em Engenharia de Sistemas e Computação pela COPPE/UFRJ, Especialista em Métodos Estatísticos Computacionais e Bacharel em Matemática com Habilitação em Informática pela UFJF UFJF..
69 ª Edição Edição - 2014
Corpo Editorial Editor
Eduardo Oliveira Spínola
Rodrigo Oliveira Spínola
[email protected] É Colaborador das revistas Engenharia de Software Software Magazine, Java Magazine e SQL Magazine.É bacharel em Ciência da Computação pela Universidade Salvador (UNIFACS). (UNIFACS).
Colaboradores
Marco Antônio Pereira Araújo Eduardo Oliveira Spínola Nicolli Souza Rios Alves Consultora Técnica
Nicolli Souza Rios Alves
Daniella Costa
[email protected]
Bacharel em Ciência da Computação na Universidade Salvador (UNIFACS),Mestranda em Sistemas e Computação no Programa de Pós-Graduação em Sistemas e Computação da UNIFACS UNIFACS na linha de Engenharia de Software.É editora da Engenharia de Software Magazine.
Jornalista Responsável Responsável
Kaline Dolabella - JP24185 Na Web
http://www.devmedia.com.br/revista-engenharia-de-software-magazine
Atendimento ao Leitor
Fale com o Editor!
A DevMedia conta com um departamento exclusivo para o atendimento ao leitor. Se você tiver algum problema no recebime nto do seu exemplar ou precisar de algum esclarecimento sobre assinaturas, exemplares anteriores, endereço de bancas de jornal, entre outros, outros, entre em contato contato com:
É muito importante para a equipe saber o que você está achando da revista: que tipo de artigo você
www.devmedia.com.br/central (21) 3382-5038
Publicidade
Para informações sobre veiculação de anúncio na revista ou no site entre em contato com: publicidade@de publici dade@devmedia. vmedia.com.br com.br
gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou. Fique a vontade para entrar em contato com os editores e dar a sua sugestão! Se você estiver interessado em publicar um artigo na revista ou no site ES Magazine, entre em contato com os editores, informando informando o título e mini-resumo do tema que você gostaria de publicar.
Sumário Conteúdo sobre Agilidade
06 – Scrum: uma visão prática do framework [ Roberto Passani ]
Conteúdo sobre Boas Práticas
11 – PMBOK: Trabalhando com gerenciamento de custos [ Fabiana de Lima ]
Conteúdo sobre Boas Práticas
18 – Riscos em projetos de software com PMBOK [ Jhoney Lopes e José Luis Braga ]
Conteúdo sobre Boas Práticas
30 – Gerência de Projetos: Monitore e controle o desenvolvimento de software [ Rommel Gabriel Gonçalves Ramos e Daniel Couto Gatti ] u
e s ê
Conteúdo sobre Boas Práticas
F eedb ac k
D
o
s
35 – Gestão de Projetos: Usando processos de desenvolvimento [ Rommel Gabriel Gonçalves Ramos e Daniel Couto Gatti ]
b r e e s t a
e
i d ç o ã Artigo no estilo Prático
43 – ITIL: Como implantar o gerenciamento de mudanças [ Cristiane Aparecida Lana e Bruno Torres Satler ]
Conteúdo sobre Boas Práticas, Conteúdo sobre Arquitetura e desenvolvimento
55 – Boas práticas de programação [ Leandro Tavares Siciliano ]
Dê seu feedback sobre esta edição! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista! www.devmedia.com.br/esmag/feedback
Edição 05 - Engenharia de Software Magazine 5
Agilidade Nesta seção você encontra artigos voltados para as práticas e métodos ágeis.
Scrum: uma visão prática do framework Fique por dentro:
O
Roberto Passani
[email protected]
Quase oito anos de experiência com testes de software, iniciado em qualidade de sistema operacional de aparelhos celulares, depois banco de dados, sistema de investimentos, plataforma de e-commerce e atualmente atuando com aplicativos móveis.Há pouco menos de um ano atuando em projeto de aplicativos móveis. Recentemente teve a oportunidade de conhecer mais do processo Scrum na prática.
6
Scrum é uma abordagem ágil que prima pela otimização e objetividade no processo e em todas suas etapas, costuma minimizar burocracias, documentação e módulos em relação a outros processos (como RUP). Tudo é baseado nas reuniões do processo (que são muitas). Entre uma reunião e outra o trabalho é realizado. Essas reuniões são importantes ao ponto de algumas empresas não usarem nenhuma documentação escrita, ou seja, fazem Sprints semanais e reuniões às segundas e sextas, de Planning e Review respectivamente, onde fazem todo o tracking das atividades e desenvolvimento do produto. Neste artigo usaremos o modelo de um Sprint de 10 dias úteis, ou aproximadamente 14 dias corridos, sendo o Planning no primeiro dia e o Review no último. Após o Review ocorre a Retrospectiva e no decorrer do Sprint o pré-planning. Diariamente devem ocorrer as reuniões Diárias (Daily Meetings). Todas essas etapas são detalhadas no artigo.
Engenharia de Software Magazine - Scrum: uma visão prática do framework
Esse artigo se propõe a mostrar uma abordagem prática do Scrum da forma como é aplicado em um projeto real, detalhando os papéis e funções de cada participante, cada etapa do processo e sua importância para que o projeto e a equipe ganhem maturidade e evoluam de forma que se obtenha um produto com qualidade e que obedece às regras da plataforma utilizada.
A equipe na qual este artigo foi baseado é constituída uma Product Owner, um Scrum Master (que também acumula funções de Coordenador), um Analista de Testes (o autor do artigo), uma Designer, um Analista de UX (User Experience) e quatro desenvolvedores, que se dividem entre as plataformas iOS e Android, fora outras pessoas que auxiliam a equipe, como analistas de produto, infraestrutura e outros. A manutenção do processo é responsabilidade do Scrum Master, ou seja, marcar todas as reuniões, garantir a presença de toda a equipe, comandar as reuniões em si, escrever no sistema de gerenciamento do processo, auxiliar no desenvolvimento dos critérios de aceite, avaliar questões de serviço, backend e etc.
AGILIDADE
Definição do Projeto O primeiro passo para desenvolvimento de um sistema no Scrum seria a reunião de pre-planning (pré-planejamento), onde são definidos o objetivo principal do sistema, isto é, aquilo que ele deseja atingir: o mercado, o público e a/as funcionalidade(s) principal(ais) - para um aplicativo, por exemplo, seja trânsito, notícias, compras ou futebol - onde são pré-planejadas as histórias que iniciarão o desenvolvimento, e nelas são inseridos os critérios de aceite ou entrega. Estes são basicamente os requisitos do sistema, o detalhamento de todas as funcionalidades, desde as mais simples àquelas principais. O título das histórias devem ser escritos na perspectiva de quem desejam atingir, por exemplo: “Eu, como cliente, quero que o aplicativo faça…” ou “Eu, como área de negócios da empresa, quero inserir a logomarca de nosso patrocinador…”, ou ainda, “Eu, como Product Owner, quero ver uma mensagem de erro quando o usuário executar uma ação indevida…”. Isso facilita analisar quem deve aprovar a história. Caso exista alguém além do Product Owner, o Scrum Master consegue analisar se há alguém além dos participantes diretos do projeto que deva ser convidado para os ritos, como Plann ing e Review, se há alguém externo à equipe que deseja inserir histórias ou acrescentar algo ao sistema. Todos devem participar desse processo, ajudar na definição dos critérios, ajudar no levantamento de critérios de exceção, mensagens de erro e possíveis cenários que faltam definição. A equipe deve ser unida profissionalmente e ter o objetivo comum de entregar o melhor sistema possível. E o analista de testes já inicia a escrita dos testes baseado nesses requisitos, criando todos os testes de validação, exceção, carga, performance, e o que mais for necessário, muitas vezes já escrevendo os testes (apenas com objet ivo) na própria reunião, através de um bloco de notas, caderno ou qualquer outra ferra menta. Já a equipe de desenvolvimento pode começar a pensar em todo o backend (serviços e servidores) necessário, e tudo que será preciso para a implementação do sistema.
Faça-se um sistema Uma vez estruturado o backend de serviços, a equipe pode começar a implementação do software, e para priorizar as histórias e analisar quais farão parte de um primeiro sprint realiza-se uma primeira reunião de planning, onde as histórias iniciais são colocadas no primeiro sprint e priorizadas na ordem decrescente dentro dele. Primeiramente colocam-se todas as histórias que precisam ser feitas e depois elas são priorizadas. Em seguida, pontua-se cada história de acordo com o critério utilizado no projeto (Fibonacci, por horas ou outro), daí podemos analisar se ainda é possível inserir alguma história, se a meta de pontos não estiver sido atingida, ou se alguma história deverá sair se a meta estiver sido ultrapassada. Caso a meta tenha sido ultrapassada e a quantidade de pontos das histórias for maior do que os pontos ultrapassados, então a última história, segundo os critérios de priorização, poderá ser dividida em duas.
Um Sprint nunca deve ser iniciado com a quantidade de pontos excedida, com histórias que possuem critérios de aceite não definidos, sem layout ou definição de UX incompleta. Por isso, se a quantidade de pontos for excedida e não houver a possibilidade de troca com outra história, então os cr itérios de aceite devem ser divididos em duas histórias, sendo uma no Sprint atual, fechando o sprint dentro da métrica de pontuação e outra como a primeira história do próximo (segundo), abrindo o próximo sprint com os pontos e critérios de aceite que restaram, devendo ser devidamente entregue cada uma em seu sprint. No planning, todo o layout e definições de UX já devem estar prontos e aprovados pelo “Product Owner”, tudo já deve esta r disponível para análise da equipe de testes e desenvolvimento. No caso de aplicativos móveis é necessário ter a tela completa e também cada botão separado, cada ícone, com todas as definições de tela para iOS: retina e não-retina, e para Android: LDPI, MDPI, HDPI, XHDPI, XXHDPI. O ideal é anexar todas as imagens na história para facilitar o acesso para a equipe otimizando o tempo e evitando ter que buscar em Drivers, e-mail, e etc., ou em um sistema de pastas que nem sempre é claro para todos. Portanto, para realizar o desenvolvimento, todas as histórias do sprint que está para se iniciar precisam ter status de definidas na ferramenta usada pela empresa, que indica que todos os dados aqui descritos já foram detalhados, anexados à história e/ou link tenha sido disponibilizado.
Iniciando o desenvolvimento Logo após o planning, o Scrum Master deve marcar o préplanning, review e planning que estão por vir, para 10 dias úteis após o primeiro planning, considerando que o planning já ocorre no primeiro dia do sprint e o review no último. Neste cenário, se o planning ocorre em uma segunda-feira dia 01, então o pré-planning deve ser marcado para quarta-feira dia 10 (aproximadamente) e o Review exatamente para o dia 12, sexta-feira. Tudo isso deve ser marcado com antecedência para que as datas de todos os ritos sejam de conhecimento de todos da equipe evitando atrasos por indisponibilidade de local ou surpresa em sua realização. No projeto é utilizado o TDD, ou seja, Test Driven Development, porém um TDD um pouco diferente, não baseado em testes unitários ou automatizados, mas baseado nos testes funcionais escritos a partir dos critérios de aceite definidos no pré-planning. Os testes da primeira história da ordem de priorização devem ficar prontos antes do início do Sprint. O desenvolvedor segue os casos de testes para criar o sistema. Portanto, o analista de testes já deve ter todos os testes escr itos e detalhados a essa altura do processo com a maior cobertura possível de forma otimizada. Esses testes devem estar disponíveis na ferramenta para análise dos desenvolvedores evitando paradas e atrasos no desenvolvimento, pois todas as perguntas já devem ter sido levantadas e respondidas, todas as mensagens de erro, validação e exceção com a cobertura adequada de forma que nenhuma demanda tenha que ser coberta no meio processo. Edição 69 - Engenharia de Software Magazine
7
Conforme as histórias forem sendo iniciadas, elas vão obtendo status de progresso na ferramenta. Após isso, quando forem sendo completadas, já podem ser disponibilizadas para teste. No caso de aplicativos móveis, é gerado um build que é instalado no aparelho, e os analistas de testes podem analisar as funcionalidades já implementadas. Uma vez encontrados erros, eles devem ser registrados na ferramenta e, se bloquearem a história e não forem recorrentes, devem ser corrigidos no próprio sprint. Caso sejam erros recorrentes ou que não bloqueiam a história ou seus critérios de aceite, eles podem ser deixados no backlog para priorização posterior. Uma vez registrados bugs que ficam no sprint, eles devem então ser corrigidos em um novo build do sistema, e todos os testes da nova funcionalidade devem ser reexecutados para garantir que a correção de um defeito não gerou erros em outras partes da nova funcionalidade. Esse processo é repetido até que todos os testes sejam executados e nenhum erro seja encontrado. Feito isso, a história poderá obter o status de completa na ferramenta e poderá ser liberada para o Review que ocorrerá no último dia do sprint. Diariamente, na rotina do projeto e com horário f ixo, sempre com a presença de todos ou o máximo possível de componentes da equipe, deve ocorrer a “Daily Meeting” (Reunião Diária), onde todos devem resumir suas atividades do projeto desde a daily meeting anterior, tentando detalhar as ações e que métodos usou para atingir seus objetivos, abrindo espaço para que os colegas possam auxiliar em dúvidas ou se utilizar dos dados ali compartilhados como lições aprendidas ou melhores práticas. Na prática, sempre pode ocorrer de critérios de aceite ou exceção não terem sido definidos ou algum layout ou definição de UX aparecer de última hora durante o Sprint. Nesse caso, devem ser tratados com urgência, uma vez que o desenvolvimento pode ficar parado até que artefatos sejam criados. O responsável pela experiência de usuário (UX) ou designer precisam ser chamados com urgência e criar o material necessário com o menor impacto possível no sprint para evitar atrasos na entrega e remarcação do review. Caso essa solução se torne demasiadamente grande e o impacto inevitável, então a história pode ter a prioridade reduzida para o fi m do Sprint, quando a definição ou artefatos necessários estarão prontos. Caso isso ainda não seja o basta nte, então podemos adiantar o fim do Sprint e essa poderá ser a primeira história do próximo, porém a Review nunca deve ser adiada e o Sprint alongado, pois o impacto disso a longo prazo é muito negativo, salvo em condições excepcionais.
A entrega – Versão 1.0 Após finalizado o processo de desenvolvimento, passadas muitas daily meetings e muitas linhas de código, ocorre a primeira reunião de Review. A primeira versão poderá ser entregue, as funcionalidades devem ser preparadas e o ambiente todo pronto para a análise do product owner. Ao iniciar a reunião, o sistema sob análise deve estar disponível para o “Product Owner” e as histórias devem ser exibidas
8
para todos, de preferência no projetor, e os critérios de aceite vão sendo passados ponto a ponto para análise do cliente. Ele pode realizar os testes necessários e passar por seus critérios de pronto. Quando finalizadas, as histórias obtêm status de ”approved” no sistema e o cliente passa a a nalisar a próxima. Caso a história não seja completa e os critérios de aceite não sejam todos atingidos, ela deve sofrer uma split, ser dividida em duas, onde a segunda história poderá ser a primeira do próximo Sprint e terá os critérios de aceite que faltam para completar. Algumas ferramentas automaticamente repassam as tarefas incompletas para a história do próximo sprint. Caso os critérios de pronto do cliente é que não sejam atendidos, ou seja, ele visualizar novos critérios de aceite que deveriam ser atingidos para que a história possa receber o deploy e ficar disponível para o usuário final, o que geralmente ocorre com critérios de exceção ou mensagens de erro, então deve ser criada uma nova história para um sprint futuro e que será priorizada no planning. Essa deve conter os novos critérios de aceite que finalizam a nova funcionalidade.
Pré-Planning – Sprint 2 Durante o Sprint, deve ser realizada a reunião pré-plann ing. Nela devem ser enriquecidas as histórias para o Sprint 2, inserir critérios de aceite e priorizar histórias de UX, design e backend; para que tudo esteja pronto quando houver o planning.
Retrospectiva do primeiro Sprint Após o planning, logo após o fim do Sprint, deve ser feita uma reunião de retrospectiva. Nela se deve relatar como foram os últimos dias (do Sprint), todas as atividades de sucesso, boas práticas, lições aprendidas e “à melhorar” para obter um processo mais sólido e rico, satisfatório para todos. Geralmente abordam-se primeiro os pontos positivos, mas não é uma regra. Cada participante do projeto deve ter oportunidade de colocar seu post-it no quadro, falar sobre o que desejar, geralmente são questões que deram certo nas atividades de uma pessoa e ela deseja compartilhar com os outros membros, abrir discussão sobre o ponto apresentado e detalhar melhor sobre o tópico. Após essa etapa discutem-se os pontos de melhoria, que costumam gerar mais polêmica e deixar ânimos exaltados. Todos devem se sentir à vontade para falar de qualquer tópico: desde a internet no ambiente de trabalho, relacionamento com outras equipes, ar-condicionado, assim como questões técnicas que influenciam diretamente no projeto como design, UX, critérios de aceite, formato de código, algoritmos, processo, links, atuação de colegas; ou tudo aquilo que não foi satisfatório e pode melhorar nas etapas futuras do processo. Após apresentados e discutidos os dois lados do último sprint, ações de melhoria devem ser tomadas, ou seja, Product Owner, Scrum Master e Coordenador devem definir como e onde podem agir para tentar resolver ou, ao menos, apaziguar os pontos de melhoria do projeto que dependem de ação externa. Relacionamento com outras equipes, ações com a gerência da área ou até com as diretorias da empresa com o objetivo de
Engenharia de Software Magazine - Scrum: uma visão prática do framework
AGILIDADE
tornar o ambiente do projeto o melhor possível, ações internas, como performance de um colaborador específico ou mudanças no processo devem ser resolvidas internamente e monitoradas durante as daily meetings do próximo sprint. Muitos projetos não veem importância na retrospectiva, principalmente com a evolução dos sprints onde o processo fica mais sólido e as retrospectivas se tornam repetitivas. Porém, só há evolução do projeto se houver reuniões de retrospectivas bem feitas. É importante também estar atento ao fato de que ninguém pode levar os pontos de melhoria para o lado pessoal. Essa é uma reunião para um processo de maturidade e o conceito é altamente profissional com objetivo de fazer um trabalho melhor.
Planning - Sprint #2 Após a retrospectiva, analisados os pontos positivos e definidos os pontos de melhoria, ocorre o Planning para definir o segundo sprint. As ações de melhoria já devem começar a ser adotadas imediatamente, e o processo se reinicia, h istórias devem ser priorizadas. Se houve história com split no sprint anterior, então essas podem ser as primeiras, porém não é obrigatório, por isso os branches devem estar bem organizados para que uma história com menor prioridade possa ser continuada em um sprint posterior sem uma linha de aprendizado muito longa. Após priorizadas as histórias, deve-se discutir a pontuação, e definir as histórias que ficam no Sprint e quais serão adiadas para os próximos sprints. Devem ser evitadas discussões paralelas nas reuniões. No Planning algumas pessoas tendem a sair do foco, gostam de opinar, porém é o Product Owner quem define, as prioridades são dele e da área de negócios. É necessário manter o objetivo de construir o Sprint rapidamente para retornar ao desenvolvimento, porém sem deixar pontos indefinidos, como dito antes, todo o design, UX, backend, serviços, etc., precisa estar definido antes de iniciar o Sprint.
é realizada corretamente em cada reunião a que pertence, garantir que todos estão executando suas atividades no momento certo do projeto, se o desenvolvimento segue padrões de qualidade, testes unitários, design patterns, métricas, buscar novas formas de atingir metas assim como, analisar se o analista de testes (ou qualidade) está seguindo corretamente o processo, escrevendo os objetivos de testes no pré-planning, se os testes da primeira história já estão prontos após o planning (para iniciar o desenvolvimento), se a cobertura dos cenários de testes está adequada, coordenar se o processo é corretamente seguido, bem próximo dos analistas que fazem com que ele ocorra. Seu excedente pode ser analisar o sistema e ver se há formas diferentes e talvez melhores de fazer o mesmo, pesquisar, procurar se inteirar nos documentos sobre sistemas similares e analisar se há novos padrões sendo adotados, procurar o que há de mais moderno, quais os caminhos que estão sendo seguidos para obter o melhor desse modelo de sistema, assim como também do processo. Seguir práticas, discussões em fóruns, ler as revistas especializadas e obter dados de como otimizar o processo sem denegrir a qualidade, ou seja, o ScrumMaster deve ser sempre muito dedicado e proativo, muito curioso e ciente das atividades diversas para ver falhas onde não estão olhando, seja no desenvolvimento ou nos testes, sempre com objetivo de aprimorar onde pode haver algum tipo de evolução.
Descrição dos papéis Para explicar melhor as atividades durante o processo de desenvolvimento de software, é interessante esclarecer as funções e papéis de cada ator no processo, o que é esperado de cada um e onde ele pode fazer algo mais, o “quilômetro extra” (versão brasileira da “Extra Mile” americana, que é aquilo feito além do esperado, além das responsabilidades) por onde se pode andar, onde se pode auxiliar na melhoria do processo para obter mais qualidade do sistema e mais satisfação do cliente. Eventualmente, em um processo de maturidade elevada e profissional, as pessoas opinam na forma como os colegas atuam, ou seja, o desenvolvedor tenta melhorar o processo de testes, o anali sta de testes ajuda o Scrum Master e esse pode ajudar nas funçõe s do “Product Owner” ou coordenador, por exemplo. Scrum Master
Sua função principal é definir e manter o processo sendo seguido, marcar e manter os ritos, garantir a presença de todos (ou o máximo possível) os participantes, ver se cada ação Edição 69 - Engenharia de Software Magazine
9
Analista de Testes
É responsável por validar e garantir a qualidade do sistema, verificar que os critérios de aceite são devidamente atendidos, nenhum bug escape ou deixe de ser registrado, que os testes regressivos continuem aumentando, sendo atualizados, evoluindo, sendo executados em todos os critérios correta mente, que o ambiente seja bem preparado para a Review, que os testes sejam bem escritos e a cobertura seja adequada já no Planning. Outra função que o analista de testes costuma ter é fornecer dados para as métricas do projeto, analisar quantos defeitos são encontrados, quantos são corrigidos e quantos novos defeitos são encontrados a partir disso. Além disso, deve fornecer esses dados para a equipe de qualidade que irá analisar o desenvolvimento do sistema e a performance dos desenvolvedores, a evolução da equipe e se o processo está sendo seguido corretamente. Desenvolvedor
É responsável por criar o sistema, elaborar as funcionalidades, seguir corretamente os testes e critérios de aceite, analisar pontos de exceção, levantar questões sobre o planning para visualizar falhas de cobertura, pontuar com critério as histórias inserindo também o tempo de testes de cada feature e o regression ao final do Sprint. Precisam também seguir o processo de testes unitários definido e garantir que haja sempre evolução na quantidade de testes e melhora na cobertura. Analista de UX (Experiência de Usuário)
É responsável pelo desenho do sistema, interfaces com usuário, a localização das funcionalidades, o resultado esperado de cada ação, que o sistema tenha a melhor usabilidade, que as funcionalidades sejam práticas, atendam padrões dos fabricantes (no caso de aplicativos móveis, por exemplo), que mensagens de erro sejam evitadas, mas, caso necessário, é responsável pelo texto da mensagem, pelo nome (“label”) dos botões. Além disso, deve analisar estatísticas do aplicativo, uso de funcionalidades e priorizar aquilo que é o foco e que o u suário mais procura no sistema. Também é responsabilidade do analista de UX pesquisar e fazer simulações com usuários, passar
10
formulários, para descobrir quais são as funcionalidades que o usuário procura, e quais melhorias enriqueceriam o sistema e trariam mais usuários. Designer
O designer de um sistema é responsável pelo layout, escolha de cores, logomarca, por aplicar o que o analista de produto (UX) projetou. Coordenador
É função do coordenador do projeto dar toda estrutura de qualidade para que a equipe de forma adequada. Normalmente, associa-se ao Scrum Master para garantir a manutenção dos ritos e que o processo seja seguido. Além disso, atua no sentido de auxiliar na correção dos pontos de melhoria. Product Owner
É o dono do projeto, o cliente. É por ele que tudo começa, quem toma as decisões, as histórias são priorizadas com a opinião de todos mas de acordo com a vontade do PO. É ele quem define os critérios de aceite, na função de cliente ele utiliza todos os estudos do designer e do analista de UX pa ra definir quais melhor se encaixam com os objetivos de projeto, e as necessidades de quem de fato utiliza o sistema. Também é função dele atuar próximo à área de negócio para ajudar a trazer patrocinadores, verba ou investimento ao projeto. No Scrum, tudo ocorre ao redor das reuniões, por isso elas são primordiais e precisam ser muito bem feitas. Essas etapas precisam ser bem obedecidas para garantir a qualidade do sistema e ter evolução no processo e no produto. Sendo bem definidas as reuniões e ficando claras as funções e responsa bilidades de cada ator, as chances de desenvolver um projeto de sucesso utilizando o Scrum serão maiores.
Você gostou deste artigo? Dê seu voto em www.devmedia.com.br/esmag/feedback Ajude-nos a manter a qualidade da revista!
Engenharia de Software Magazine - Scrum: uma visão prática do framework
Planejamento e Gerência Nesta seção você encontra artigos voltados para o planejamento e gerência de seus projetos de software.
Riscos em projetos de software com PMBOK Fique por dentro: A tarefa de gerenciar os custos do projeto engloba, além do minucioso processo de planejamento e definição dos custos e de seu gerenciamento, a definição e escolha de bons orçamentos que tragam valor agregado ao processo, e ainda, o controle de tais recursos de forma a cumprir com aquilo que foi definido inicialmente. Este artigo apresenta uma abordagem para o gerenciamento de custos em projetos da área de TI levando em consideração os principais aspectos desse tipo de gerência e mostra quais são os conhecimentos
A
Fabiana de Lima
[email protected]
Mestre em Ciência da Computação na subárea de Engenharia de Software, atua como professora e pesquisadora na área. Exerceu funções de analista de sistemas em empresas de desenvolvimento de software e de recrutamento e seleção. Atualmente, atua como professora formadora também em cursos de EAD em Maringá - PR.
área de TI para uma empresa possui orçamentos altos, a tecnologia custa caro e os elementos correspondentes também, um bom servidor, por exemplo, pode passar da casa dos R$ 15.000,00. Muitas vezes o custo não é definido pela equipe de projetos e sim pelo próprio cliente ou área supervisora da TI na empresa, que possui uma necessidade pulsante e esta belece limites de custos para resolvê-la. Com isso, as características do software ou das necessidades do cliente/área supervisora podem, e geralmente o fazem,
utilizados nos processos que o compõe, propostos pelo Guia PMBOK. O tema é útil, principalmente, para gerentes de projetos que buscam aprofundar seus conhecimentos no gerenciamento de custos em projetos de desenvolvimento de software e outros relacionados à área de TI. Serve também para desenvolvedores de software que trabalhem em equipes de projeto e que visem aprimorar seus conhecimentos em busca de minimização de custos para suas tarefas diárias, bem como, conhecer um pouco mais sobre como os recursos de um projeto são distribuídos e gerenciados.
definir uma variação no gerenciamento de custos do projeto. Por isso, essa é uma atividade extremamente dinâmica, junto com o gerenciamento do escopo e do tempo definem um tripé principal da gerência de projetos na área de TI. Ressalta-se aqui que outras áreas como a qualidade, por exemplo, são de extrema importância para um bom projeto. A tarefa de gerenciar os custos do projeto engloba, além do minucioso processo de planejamento e definição dos custos e de seu gerenciamento, a definição e escolha de bons orçamentos
Edição 69 - Engenharia de Software Magazine
11
que tragam valor agregado ao processo, e ainda, o controle de tais recursos de forma a cumprir com aquilo que foi definido inicialmente. Um projeto que envolva o desenvolvimento de software inclui as dificuldades em se manter os custos iniciais, baseados nos requisitos levantados no início do projeto até o término dele. Nisso está a importância, associada ao gerenciamento de custos, também do escopo e tempo em questão.
Os mecanismos necessários para o gerenciamento de custos Segundo o Guia de conhecimento PMBOK, são quatro os elementos necessários para o gerenciamento de custos de um projeto: o plano de gerenciamento de custos, a estimativa de custos, a determinação de orçamentos e o controle de custos. Em pequenos projetos de desenvolvimento, alguns desses processos podem estar sobrepostos, sendo executados de uma só vez como, por exemplo, o planejamento do gerenciamento e a estimativa de custos, resultando no desenvolvimento de orçamentos a serem feitos. Neste artigo, eles serão mostrados isoladamente, para que um entendimento amplo de cada processo possa ser obtido. Ressaltamos que existem outros detalhes e ferramentas utilizadas que são muito importantes para o bom gerenciamento. As tarefas de estimar custos e controlálos são as que demandam maior esforço do gerente, já que, em projetos de desenvolvimento de software as medições são complexas de serem feitas e tornam-se uma área a parte de estudos para que um bom gerenciamento de custos possa ser feito. Para a execução dos processos referentes ao gerenciamento de custos, três itens são importantes: as entradas, as ferramentas e técnicas e as saídas.
As entradas são mecanismos utilizados em cada processo, os quais podem oferecer informações ou dados referentes ao projeto, oriundos de fatores ambientais da empresa (determinações já estabelecidas e que devam ser observadas para o trabalho), ou de fatores externos (como calendário dos recursos disponíveis) ou ainda, gerados a partir de outros processos de gerenciamento do projeto (como a baseline do escopo do projeto, plano de riscos, dentre outros). Já as ferramentas e técnicas utilizadas podem ser um padrão (utilizadas em todos os projetos da empresa) ou ainda estarem sendo utilizadas pela primeira vez no projeto em questão. Elas podem ser desde estimativas de três pontos e análise de reservas, passando por custos relacionados à qualidade, até uma ferramenta de software de gerenciamento de projetos. Por sua vez, as saídas são produtos, fornecidos durante o gerenciamento de custos, relacionados à execução de um dos quatro processos, dentre esses estão as estimativas de custos das atividades, previsões orçamentárias, dentre outros. As saídas são elementos que também podem variar muito, desde atualizações no plano de gerenciamento de projeto, passando por medidas de performance de trabalho, indo até uma baseline de custos e necessidades de financiamento do projeto. Em relação aos processos que já foram citados, devemos ressaltar que em todos eles o gerenciamento de custos pode ser desenvolvido com métodos próprios ou estabelecidos para determinada área de aplicação de um projeto. A área de tecnologia da informação possui uma vasta gama de métodos de análise e medições, por exemplo, estimativas utilizadas em metodologias ágeis de desenvolvimento de software, como a partição de pontuação das estórias definidas pelo cliente,
Figura 1. Entradas, ferramentas e técnicas e saídas para o Plano de Gerenciamento de custos
12
Engenharia de Software Magazine - Riscos em projetos de software com PMBOK
ou ainda, outras métricas como a análise de pontos por função ou por casos de uso. Esses métodos auxiliam em muito o gerenciamento de custos, baseado no escopo definido através deles. Considera-se que, embora o guia trabalhe com os processos definidos, outros métodos próprios para projetos de TI e que não são tratados no PMBOK (já que o objetivo do Guia é outro), podem ser manipulados em conjunto e durante o próprio gerenciamento de custos, realizado através dos processos estabelecidos no PMBOK. A seguir, encontram-se os processos necessários para o gerenciamento de custos, exemplificados em sua maneira de coexistirem em projetos de desenvolvimento de software. Esses processos devem ocorrer pelo menos uma vez em cada projeto e serem repetidos em cada uma das fases em que um projeto for dividido. De maneira diversificada, eles fazem uso dos mecanismos (entradas, ferramentas e técnicas e saídas) apresentados.
Plano de Gerenciamento de Custos O processo de Planejar o Gerenciamento de Custos envolve a definição e o destino dos recursos disponíveis para o projeto. Em projetos de TI, normalmente esses recursos são destinados a pessoal e infraestrutura, contando algumas vezes com elementos de treinamento e implantação do produto ou serviço. A Figura 1 , retirada do Guia PMBOK, ilustra o conjunto de entradas, de ferramentas e técnicas e de saídas que estão presentes nesse primeiro processo de gerenciamento de custos, Plano do Gerenciamento de Custos. A seguir apresentam-se as entradas pertencentes a esse processo, com um exemplo de como elas podem ser conseguidas em projetos de desenvolvimento de software: • Plano de gerenciamento de projeto: é um documento que contém as diretrizes iniciais para o projeto, levando em consideração todas as áreas de gerenciamento. Ele serve como entrada, pois, contém as principais definições feitas a partir das necessidades também iniciais apresentadas pelo cliente/usuário no ato de contratação
PLANEJAMENTO
do projeto. Elementos como as formas adotadas para o trabalho, paradigmas de desenvolvimento, possibilidades de infraestrutura, participação do usuário no projeto, recursos humanos disponíveis, stakeholders, dentre outros são elementos que podem ser definidos nesse processo e documentados com maior precisão em suas respectivas áreas de processo; • Contrato do projeto: esse é um documento formal que contém uma descrição inicial sobre os requisitos do sistema, em alto nível, além de recursos financeiros disponíveis, marcos e entregas, dentre outros; • Fatores ambientais da empresa: são elementos como normas, padrões ou diretrizes estabelecidos que podem vir a influenciar nos custos de desenvolvimento do projeto; • Ativos de processo organizacional:
são elementos conseguidos a partir da realização de outros projetos na empresa, que possam vir a direcionar melhor o gerenciamento de custos do projeto. Um exemplo claro são definições anteriores de recursos necessários X áreas de trabalho, ou ainda, recursos financeiros X recursos humanos em outros projetos da área. De posse desses elementos de entrada, a tarefa de Planejar o Gerenciamento de custos pode ser executada. A partir do uso das ferramentas e técnicas a seguir, exemplificamos de forma simples seu uso para o desenvolvimento de um software: • Opinião especializada: qualquer opinião de membros técnicos pertencente ao grupo de stakeholders ou que participaram de projetos anteriores definindo e planejando custos destinados a atividades de projeto podem ser ouvidas, para que melhores estimativas dos recursos possam ser feitas no projeto; • Técnicas analíticas: a experiência no planejamento de quais técnicas poderão ser melhor aproveitadas para a definição e o gerenciamento de custos é um importante fator para o planejamento de ferramentas de auxílio ao gerenciamento de custos que se pode utilizar, qual(is) técnica(s) de análise e estimativa de recursos para as atividades será(ão)
Figura 2. Entradas, ferramentas e técnicas e saídas para o processo Estimar os Custos
utilizadas, dentre outras. Novamente, ouvir e conhecer quais softwares e técnicas são utilizadas no ambiente organizacional é uma boa prática para planejar a definição de custos que serão produzidos no projeto; • Reuniões: a equipe de projeto deve ser reunida para planejar como o gerenciamento e a distribuição dos recursos será realizada. Podem participar dessa reunião, o gerente de projetos, o patrocinador, membros da equipe selecionados, stakeholders selecionados, enfim, qualquer membro do projeto que tenha responsabilidade sobre a boa execução do gerenciamento de custos do mesmo.
à duração das atividades e do projeto como um todo. A Figura 2 , retirada do Guia PMBOK, ilustra o conjunto de entradas, de ferramentas e técnicas e de saídas que estão presentes nesse segundo processo de planejamento, Estimar os Custos. A seguir apresentam-se as entradas pertencentes a esse processo, com um exemplo de como elas podem ser conseguidas em projetos de desenvolvimento de software:
A partir da realização dessas tarefas, para o Planejamento do Gerenciamento de Custos, deve ser produzido como saída: Plano de gerenciamento de custos: em projetos de TI ele pode ser visto como um documento simples que contenha as principais atividades representativas do gerenciamento de custo em questão. Podendo conter uma análise referente a quais recursos serão destinados a pessoal, como técnicos, programadores, gerentes, possíveis serviços terceirizados, e ainda, a forma como os recursos serão destinados à infraestrutura necessária para o projeto, dentre outras.
• Plano de gerenciamento de recursos
•
Estimativa de Custos O processo de estimar os custos do projeto envolve uma análise crítica de quais serão as devidas necessidades dentro da relação espaço (atividade) X tempo do projeto. Custos em relação a mão de obra podem ser feitos, porém, é necessário que isto esteja alinhado
• Plano de gerenciamento de custos:
produzido como saída no processo anterior, tem como principal objetivo nortear a forma como o gerenciamento de custos será realizado no projeto; humanos: produzido durante o processo
de gerenciamento de recursos humanos traz pessoas, papéis e cargos referentes ao desenvolvimento de todo o projeto. Deve-se ressaltar que em todo o projeto stakeholders das mais diferentes origens podem ter participação ativa; • Linha de base do escopo: é a especificação do escopo do projeto, com as principais entregas e os requisitos de aceitação. Os documentos que vão sendo produzidos durante o planejamento do escopo fazem parte dessa base para o projeto; • Cronograma do projeto: este documento é produzido durante o processo de gerenciamento do tempo do projeto e deve conter no mínimo as datas (início e término) planejadas para as atividades, as metas, os recursos necessários e o encadeamento natural das atividades de acordo com as restrições empregadas; • Registro de riscos: conseguidos a partir do processo de gerenciamento de
Edição 69 - Engenharia de Software Magazine
13
riscos do projeto são eficientes para que fiquem claros quais são os riscos de uma seleção ou de uma disponibilização de determinado recurso do projeto, dentre outras; • Fatores ambientais da empresa: são elementos como normas, padrões ou diretrizes estabelecidos que podem vir a influenciar os custos de desenvolvimento do projeto; • Ativos de processo organizacional: são elementos conseguidos a partir da realização de outros projetos na empresa, que possam vir a direcionar melhor o gerenciamento de custos do projeto. Um exemplo claro são as linhas de base ( baselines) do projeto, ou ainda, definição de recursos produzidos em antigos projetos. De posse desses elementos de entrada, a tarefa de Estimativa dos Custos pode ser executada, a partir do uso das ferramentas e técnicas a seguir, exemplificamos de forma simples seu uso para o desenvolvimento de projetos em TI: • Opinião especializada: qualquer membro técnico pertencente ao grupo de stakeholders do projeto pode ser ouvido, para que, a partir de dados e experiências em projetos a nteriores, decisões possam ser tomadas com o intuito de realizar estimativas consistentes para o projeto em questão; • Estimativa análoga: estimar utiliza ndo essa técnica significa ter como base projetos anteriores semelhantes para o cálculo dos recursos do atual projeto. Ela necessita de menos custos para ser aplicada, porém, é também menos precisa que outras técnicas que podem ser utilizadas, como as que seguem; • Estimativa paramétrica: essa técn ica se utiliza de dados estatísticos de projetos anteriores para realizar uma estimativa para parâmetros conhecidos. Exemplo de parâmetros são orçamento, duração, dentre outros; • Estimativas de três pontos: se baseia em três casos para estimar: a análise do melhor cenário, a do pior cenário e a do cenário mais realista possível, determinado a partir das dependências e expectativas de atividades prováveis; • Análise de reservas: um esquema de identificação de percentual para reserva de trabalho, com o intuito de suprir incertezas do cronograma pode ser utilizado. Nessa técnica, conforme os dados passam a ser mais reais, as reservas podem também ser melhoradas, reduzidas ou até eliminadas; • Custo da qualidade: englobam os custos durante toda a vida do produto, como os de atendimento aos requisitos de qualidade, de retrabalho, ou ainda de prevenção do não cumprimento dos requisitos. Como custos de atendimento aos requisitos podemos citar: testes de aceitação do sistema; já os de retrabalho podem ser gerados por: falhas internas de programação ou de documentação do software; e os de prevenção: como um treinamento de usuários antes de colocar o sistema em operação; • Software de gerenciamento de projetos: existem diversas ferramentas de auxílio à definição, monitoramento e controle de recursos para as atividades de projetos. Ferramentas de controle de custos normalmente disponibilizam toda a
14
estrutura para controle dos recursos e tempo das atividades em questão. Um exemplo de software livre com es sa função é o OpenProject citado na seção Links; • Análise de proposta de fornecedor: de posse de propostas de fornecedores para o que é necessário para a realização do projeto, o gerente deve analisar as mesmas para adequar: expectativas, custos necessários e valores agregados. Isso pode levar ao resultado total de quanto o projeto custaria para ser realizado. Este ainda pode ser a soma de valores de entregas individuais do projeto, quando subprodutos do projeto devem ser desenvolvidos de forma independente; • Técnicas de tomada de decisão em grupo: nessas técnicas o envolvimento da equipe de projeto nas estimativas proporcionam maior comprometimento da mesma com os gastos previstos X realizados. Nesse contexto, técnicas como Brainstorming ou o particionamento por pontuação de estórias do cliente, usados em metodologias ágeis, são boas formas de envolvimento da equipe nas estimativas. A partir da realização dessas tarefas para a Estimativa dos Custos deve ser produzido como saída: • Estimativas de custos das atividades: as estimativas finais podem ser produzidas em detalhes ou de forma geral, de acordo com a necessidade do projeto. Essas estimativas devem conter todos os custos necessários para o desenvolvimento do projeto, inclusive custos de possíveis distorções na própria análise dos custos; • Bases das estimativas: todas as suposições e critérios utilizados para a estimativa dos custos devem estar claros para que se possa verificar possíveis erros com facilidade. Quando do uso de intervalos, do tipo valor estará entre: x-10% e x+10%) este deve estar bem especificado, não contendo somente o valor médio indicado. Enfim, tudo o que for considerado deverá estar relatado nesse tópico, independente se haverá uma descrição sucinta ou detalhada dos motivos pelos quais adotou-se tal critério; • Atualização de documentos do projeto: são produzidos de acordo com as modificações realizadas a partir do plane jamento de custos do projeto. elas podem ser de melhoria ou adequações e podem gerar modificações em diversos documentos, dependendo de sua origem. Exemplo: uma definição ou mudança nos custos do projeto, pode gerar mudanças de cronograma de atividades do projeto, mudanças no planejamento dos riscos do projeto, ou ainda, definição pa ra aquisição ao invés de produção no projeto, dentre outros.
Determinar o orçamento O processo de determinar o orçamento do projeto é uma tarefa que depende, além dos produtos (saídas) dos processos anteriores do gerenciamento de custos, também de produtos oferecidos por outros processos de gerenciamento, como o escopo e o tempo. A Figura 3 , retirada do Guia PMBOK, ilustra o conjunto de entradas, de ferramentas e técnicas e de saídas que estão presentes nesse terceiro processo de Determinar o orçamento.
Engenharia de Software Magazine - Riscos em projetos de software com PMBOK
PLANEJAMENTO
A seguir, apresenta-se as entradas pertencentes a esse processo, com um exemplo de como elas podem ser conseguidas em projetos de desenvolvimento de software: • Plano de gerenciamento de custos:
produzido como saída no inicial, tem como principal objetivo nortear a forma como o gerenciamento de custos será realizado no projeto; • Linha de base do escopo: é a especificação do escopo do projeto, com as principais entregas e os requisitos de aceitação. Os documentos que vão sendo produzidos durante o planejamento do escopo fazem parte dessa base para o projeto; • Estimativas de Custo das atividades:
obtida como saída do processo anterior traz uma visão da relação custo X atividades para os elementos do projeto; • Bases de estimativas: que também são obtidas a partir do processo anterior de forma a oferecer suporte para o orçamento total do projeto; • Cronograma do projeto: este documento é produzido durante o processo de gerenciamento do tempo do projeto e deve conter no mínimo as datas (início e término) planejadas para as atividades, as metas, os recursos necessários e o encadeamento natural das atividades de acordo com as restrições empregadas; • Calendários dos recursos: nele estarão indicadas as datas em que os recursos como materiais, pessoas ou equipamentos estarão sendo usados por outros projetos ou ainda liberados para o uso. Nesse processo a obtenção desse calendário é uma condição primordial para as estimativas. Além do que essa informação é importante, para identificar a possibilidade de trabalho de determinado membro da equipe em seu projeto; como para que o projeto esteja preparado para riscos de eventuais atrasos quando se tratar de um recurso advindo de outra região, ou que depende de fatores ambientais ou temporais (final de ano, recessos ou grandes feriados) para serem adquiridos; • Registro de riscos: conseguidos a partir do processo de gerenciamento de riscos do projeto são eficientes para que fiquem claros quais são os riscos de uma seleção ou de uma disponibilização de
determinado recurso do projeto, dentre outras; • Contratos: informações de contratos e os custos dos mesmos sejam eles para aquisições de bens ou de serviços devem ser relatados para que os custos possam fazer parte do orçamento total do projeto. Um exemplo é o contrato de serviço para fornecimento de Internet em projetos de desenvolvimento em TI; • Fatores ambientais da empresa: são elementos como normas, padrões ou diretrizes estabelecidos que podem vir a influenciar os custos de desenvolvimento do projeto; • Ativos de processo organizacional:
são elementos conseguidos a partir da realização de outros projetos na empresa, que possam vir a direcionar melhor o gerenciamento de custos do projeto. Um exemplo claro são as linhas de base (baselines) do projeto, ou ainda, definição de recursos produzidos em antigos projetos. De posse desses elementos de entrada, a tarefa de Determinar o Orçamento pode ser executada, a partir do uso das ferramentas e técnicas. A seguir, exemplificamos de forma simples seu uso para o desenvolvimento de um software: • Agregação de custos: os custos devem ser agregados de acordo com a estrutura hierárquica da EAP. Assim, custos totais de um pacote presente no nível final da EAP são agregados aos custos de outros pacotes no mesmo nível para formarem o custo total do elemento presente no EAP no nível superior a eles, consecutivamente até que o custo total do projeto possa ser calculado; • Análise de reservas: um esquema de identificação de percentual para reserva de custos, com o intuito de suprir
incertezas no orçamento pode ser utilizado. Nessa técnica, conforme os dados passam a ser mais reais, as reservas podem também ser melhoradas, reduzidas ou até eliminadas; • Opinião especializada: qualquer opinião de membros técnicos pertencente ao grupo de stakeholders ou que participaram de projetos anteriores definindo e planejando custos destinados a atividades de projeto podem ser ouvidas, para que melhores estimativas dos recursos possam ser feitas no projeto; • Relações históricas: elas podem ser utilizadas para a realização de análises paramétricas ou análogas, de forma que custos estimados em outros projetos possam servir de suporte para a definição de custos de um novo projeto; • Restrição de limites financeiros: o cronograma de projeto pode auxiliar muito na relação de definição das restrições existentes para o projeto. Tarefas em paralelo ou subsequênciais podem dispensar mais ou menos recursos. A partir da realização dessas tarefas para a Determinação do Orçamento as seguintes saídas devem ser produzidas: • Linha de base de custos: relaciona-se ao orçamento total do projeto em função do tempo e de pequenos orçamentos intermediários de entregas e marcos particulares. • Requisitos de recursos financeiros do projeto: produzidos para que os recur-
sos necessários para o projeto possam ser adquiridos ao longo do desenvolvimento do mesmo, sem perda de poder de execução, antecipando os mesmos para sua aplicação no tempo devido. • Atualização de documentos do projeto: são
produzidos de acordo com
Figura 3. Entradas, ferramentas e técnicas e saídas para a Determinação do Orçamento
Edição 69 - Engenharia de Software Magazine
15
as modificações realizadas a partir da determinação do projeto. elas podem ser de melhoria ou adequações e podem gerar modificações em diversos documentos, dependendo de sua origem. Exemplo: uma definição ou mudança no orçamento do projeto, pode gerar mudanças de cronograma de atividades do projeto, mudanças no planejamento dos riscos do projeto, ou ainda, definição para aquisição ao invés de produção no projeto, dentre outros.
Controlar os custos O Controle de custos do projeto deve ser realizado durante todo o projeto. Assim, possíveis distorções encontradas durante a execução do projeto podem ser minimizadas em fases posteriores e antes do término para que possam ser recuperadas. A Figura 4 , retirada do Guia PMBOK, ilustra o conjunto de entradas, de ferramentas e técnicas e de saídas que estão presentes nesse último processo de Controlar os Custos. A seguir, apresenta-se as entradas pertencentes a esse processo, com um exemplo de como elas podem ser conseguidas em projetos de desenvolvimento de software: • Plano de gerenciamento de projeto: é um documento que contém as diretrizes iniciais para o projeto, levando em consideração todas as áreas de gerenciamento. Ele serve como entrada, pois, contém as principais definições feitas a partir das necessidades também iniciais apresentadas pelo cliente/usuário no ato de contratação do projeto. Elementos como as formas adotadas para o trabalho, paradigmas de desenvolvimento, possi bilidades de infraestrutura, participação
do usuário no projeto, recursos humanos disponíveis, stakeholders, dentre outros são elementos que podem ser definidos nesse processo e documentados com maior precisão em suas respectivas áreas de processo; • Requisitos de recursos financeiros do projeto: produzidos no processo an-
terior para que os recursos necessários para o projeto possam ser adquiridos ao longo do desenvolvimento do mesmo, sem perda de poder de execução, antecipando os mesmos para sua aplicação no tempo devido; • Dados de performance do trabalho:
é a forma de medir o andamento das atividades verificando, por exemplo, o cumprimento de tarefas e os custos necessários para executá-las; • Ativos de processo organizacional:
são elementos conseguidos a partir da realização de outros projetos na empresa, que possam vir a direcionar melhor o gerenciamento de custos do projeto. Um exemplo claro são definições anteriores de recursos necessários X áreas de trabalho, ou ainda, recursos financeiros X recursos humanos em outros projetos da área.
durante a realização do mesmo, pode prever melhorias no próprio orçamento definido previamente, realizando, assim, também as revisões de performance; • Software de gerenciamento de projetos: existem
diversas ferramentas de auxílio à definição, monitoramento e controle de recursos para as atividades de projetos. Ferramentas de controle de custos normalmente disponibilizam toda a estrutura para controle dos recursos e tempo das atividades em questão, como citado anteriormente; • Análise de reserva: um esquema de identificação de percentual para reserva de trabalho, com o intuito de suprir incertezas do cronograma pode ser utilizado. Nessa técnica, conforme os dados passam a ser mais reais, as reservas podem também ser melhoradas, reduzidas ou até eliminadas. A partir da execução das tarefas necessárias para o Controle dos Custos as seguintes saídas devem ser produzidas: • Informação da performance do traba-
• Previsões, índice de performance
serão geradas a partir das análises feitas durante todo o processo de gerenciamento e devem ser mapeadas nos seus respectivos documentos de projeto; • Previsões de custo: os orçamentos realizados devem então serem comunicados às partes necessárias para que possam ser utilizados; • Solicitações de mudanças: com base na performance, na definição de orçamento e ainda em mudanças de escopo e tempo, possíveis solicitações de mudanças podem vir a ocorrer de forma a integrar novamente o projeto em suas áreas de gerenciamento;
para conclusão: baseado nos índices de
• Atualização do plano de gerencia-
desempenho de projeto a equipe, ainda
mento do projeto: o plano de gerencia-
De posse desses elementos de entrada, a tarefa de Controle dos Custos pode ser executada, a partir do uso das ferramentas e técnicas a seguir, exemplificamos de forma simples seu uso para o desenvolvimento de um software: • Gerenciamento do valor agregado:
deve ser usado, utilizando-se custos, tempo e atividades, para cálculo de performance do projeto;
lho:
mento do projeto deve ser atualizado para conter as definições necessárias que estabelecidas a partir do gerenciamento dos custos que foi realizado; • Atualização do documento de pro-
o documento de projeto deve ser atualizado para conter as definições necessárias e que foram estabelecidas a partir do gerenciamento dos custos que foi realizado; jeto:
• Atualização dos ativos de procesFigura 4. Entradas, ferramentas e técnicas e saídas para o Controle dos Custos
16
Engenharia de Software Magazine - Riscos em projetos de software com PMBOK
sos organizacionais:
atualizações nos
PLANEJAMENTO
documentos que contém dados, conseguidos a partir da realização de outros projetos na empresa, devem ser atualizados com os dados do projeto atual para possíveis futuras experiências. Sabemos que o gerenciamento deve ser iniciado com um planejamento para o mesmo tendo como base diversos d iversos elementos do projeto, tais como, as atividades definidas no gerenciamento gerencia mento do escopo e o cronograma do projeto. projeto. Essas três grandes áreas do gerenciamento (trazidas pelo PMBOK) tempo, escopo e custos estão intrinsecamente relacionadas, criando-se uma dependência mútua entre as mesmas. Os conhecimentos apresentados não fornecem um padrão, eles se traduzem por um Guia, que pode ser modificado, melhorado ou seguido em sua completude de acordo com o projeto a ser gerenciado. Ressalta-se aqui que esses processos possuem uma lógica sequencial didática, porém, sua execução pode ter atividades sobrepostas em muitos casos, durante o Gerenciamento dos Custos, como por exemplo, exemplo, as atividades de estimar os custos e definir o orçamento.
Os processos estabelecidos devem também se relacionar com outras áreas de gerenciamento de projetos descritas no PMBOK. Ora oferecendo entradas para outros proc essos, ora recebendo como entrada elementos produzidos por eles e q ue serão necessários para o desenvolvimento do Gerenciamento dos Custos. Links: PMI no Brasil – a Maior Associação Mundial para Profissionais de Gerenciamento de Projetos http://brasil.pmi.org/ Página do projeto OpenProject http://sourceforge.n http://sourc eforge.net/projects/openpr et/projects/openproj/ oj/
Você gostou deste artigo? Dê seu voto em www.devmedia.com.br/esmag/feedback Ajude-nos a manter a qualidade da revista!
Edição 69 - Engenharia de Software Magazine
17
Planejamento e Gerência Nesta seção você encontra artigos voltados para o planejamento e gerência de seus projetos de software.
Riscos em projetos de software com PMBOK Fique por dentro:
Jhoney Lopes
[email protected] jhoney.lope
[email protected]
Bacharel e mestrando em Ciência da Computação pela Universidade Federal de Viçosa. Atua na área de Ciência da Computação, com ênfase em Engenharia de Software.DesenvolSoftware. Desenvolvedor iOS, Embaixador certificado em Negócios Sociais no Brasil e co-criador do Catálise Social (www.catalisesocial.com). Áreas de interesse: Engenharia de Software, Empreendedorismo, Gerenciamento de Projetos e Risco.
José Luis Braga
[email protected] [email protected] .br
Pós-doutoramento em Tecnologias da Informação na University of Florida (1988-1999). Doutor em Informática-Departamento de Informática da PUC-Rio (1990). Mestre em Ciências da Computação-Departamento de Ciência da Computação da UFMG (1980). Atualmente é Professor Titular do Departamento de Informática do Centro de Ciências Exatas e Tecnológicas da Universidade Federal de Viçosa-MG. Atua na área de Ciência da Computação, com ênfase em Engenharia de Software e Sistemas de Informação.
18
A gerência de projetos é amplamente estudada e possui diversas ferramentas que auxiliam na eficiência e eficácia da produção de software. Uma de suas atribuições é o gerenciamento de riscos, pois existem inúmeros riscos que envolvem o desenvolvimento de software Riscos são situações de incertezas que envolvem escolhas relacionadas com decisões que estão ligadas diretamente aos riscos. Uma vez conhecidos os riscos, as decisões podem reduzir perdas, aumentar ganhos ou, o contrário, levando a prejuízos.
R
isco é falta de informação, a incerteza é a base do risco, por essa razão ele está no futuro. O passado é conhecido, logo é possível saber quais incertezas afetaram positivamente ou negativamente. Por mais que cada pessoa seja única e viva experiências individuais, o cotidiano é cercado de influências comuns, que fornecem informações que são mapeadas e utilizadas por todos como, por exemplo, o melhor caminho para ir ao trabalho, o melhor tipo de investimento, quanto
Engenharia de Software Magazine - Riscos em projetos de software com PMBOK
O objetivo principal do artigo é apresentar fatores de risco que impactam o desenvolvimento de software, classificá-los em grupos e proporcionar uma visão dos relacionamentos entre eles e como essas informações auxiliam na tomada de decisões. O tema é útil para auxiliar no gerenciamento de projetos de soft ware, como método de controle dos possíveis riscos que impactam o desenvolvimento do projeto. O uso desse conhecimento é indispensável para evitar perdas financeiras, atrasos, erros, retrabalhos e perdas de outros recursos.
tempo gasta-se de casa até o destino final, e outros. Risco não é associado com certeza, sendo assim, quando uma ação é de risco, não se pode definir a mesma sendo ruim ou boa. Existem diversos esportes de alto risco como, por exemplo, o paraquedismo. Durante um salto, o paraquedas pode desdobrar no ar da melhor maneira possível, mas em outros casos isso pode não acontecer. As pessoas não deixaram deixara m de praticar praticar o esporte por causa desse perigo, elas mapearam as formas
PLANEJAMENTO
indesejadas da abertura abert ura do paraquedas e desenvolveram técnicas para lidar com cada uma delas. Criar soluções para lidar com as incertezas não s e restringe ao esporte. Inovar Inovar é assumir riscos e é necessário arrisca r para quebrar o “status quo”. Sejam inovações disruptivas (ver BOX 1), em processos, em modelos ou outros, a intenção é aproveitar uma oportunidade para melhorar algo. Essa buscaa pela busc p ela melhor melhoria ia const c onstante ante obriga a esbar e sbarrar rar cont continua inua-mente com o desconhecido. Todo caminho novo tem incertezas associadas, mas muitas vezes possui características que interceptam com outros já conhecidos. Gerenciar riscos é utilizar de conhecimentos prévios para minimizar efeitos indesejados.. Este artigo indesejados art igo fornece um conjunto de informações para auxiliar auxil iar o gerente de projetos a enxergar os pontos positivos e negativos das decisões em projetos de software. BOX 1. Inovações disruptivas
Disruptivo é algo que quebra conceitos, ruptura ou rompimento de algo. Uma inovação disruptiva é um produto,serviço ou tecnologia que rompe ideias preestabelecidas, ou ou seja, algo que extrapola o até então conhecido.
O risco pode ser visto de várias formas. Primeiro, risco gira em torno dos acontecimentos futuros. A questão é: pode-se mudar ações hoje, a fim de criar oportunidades para uma melhor situação amanhã? amanh ã? Segundo, risco envolve envolve mudanças, tais como mudança de mentalidade, opinião, opin ião, ações, ou lugares. Em um mundo estático, não existe risco, risc o, logo, logo, esse é o terceiro aspecto do risco. Risco envolve escolhas, e todas as incerteza s que essas escolhas trazem. O gerenciamento dos riscos em áreas como administração, economia, estatística e matemática financeira, fina nceira, além de ser muito empregado é tratado como elemento chave para tomada de decisão. O risco envolvido em projetos é uma condição condiç ão ou evento incerto que, se ocorrer, terá um efeito positivo ou negativo. Esses efeitos podem ser no prazo, custo, esforço e qualidade. qual idade. Um Um risco pode ter diversas causas e, se ele acontecer, pode ter diversos impactos. Uma causa é uma condição que favorece o acontecime acontecimento nto de resultados positivos ou negativos. negat ivos. Por Por exemplo, a causa pode ser uma mudança no escopo, a falta de conhecimento ou pessoas insuficientes para executar um projeto, entre outros. O processo de manipulação dos riscos é realizado com a análise e gerenciamento. Na análise estão as etapas de identificação, identificaç ão, estimativa e avaliação, já o gerenciamento é entendido como controle do planejamento e o monitoramento do sucesso dos mecanismos mecan ismos de controle. Esse processo tem como objetivo básico observar o que pode dar errado e auxiliar nas tomadas decisões. A Figura 1 apresenta a visão geral do gerenciamento de riscos apresentado no PMBOK e possui os seguintes segui ntes itens: • Planejamento do gerenciamento de risco: o processo de definição de como conduzir as atividades do gerenciamento de risco; • Identificação dos riscos: processo de determinação de quais riscos podem afetar o projeto e documentação de suas características;
• Análise qualitativa dos riscos: processo de priorização dos
riscos para análise ou ação adicional através da avaliação e combinação de sua probabilidade de ocorrência e impacto; • Análise quantitativa dos riscos: o processo de analisar numericamente o efeito dos riscos identif icados nos objetivos gerais do projeto; • Planejamento de respostas aos riscos: processo de desenvolvimento de opções e ações para aumentar oportunidades e reduzir ameaças ameaça s aos objetivos do projeto; • Monitoramento e controle de riscos: processo de implementação de planos de respostas aos riscos, acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificação de novos riscos, e avaliação da eficácia do processo de risco durante dura nte todo o projeto. Na figura são apresentadas as entradas, ferramentas técnicas e saídas dos principais pri ncipais processos de gerenciamento de risco. Para obter sucesso, uma organização deve estar compromissada em realizar gerenciamento de risco de forma proativa e consciente. Uma escolha consciente deve ser f eita em todos os níveis da organização para identificar e segui r um efetivo gerenciamento de risco durante todo o ciclo de v ida de um projeto. O gerente de projetos projetos pode utilizar a Figura 1 para organizar um plano de ação de gerenciamento de risco. A gestão de riscos tornou-se uma preocupação global, os efeitos indesejados dos riscos se transformaram em uma apreensão. Por esse motivo, em 2009, saiu a norma ISO 31 31000 000 e no Brasil foi lançada em 30/11/2009 a ABNT NBR ISO 31000 - Gestão de Riscos, Princípios e Diretrizes. Diretri zes. A norma ISO 31000 31000 tem reconhecimento internacional, não tem finalidade de certificação, mas é uma ferramenta de auxílio às empresas, trazendo uma forte vantagem competitiva. Observa-se que os projetos de desenvolvimento de software, em geral, apresentam atrasos de cronogramas, custos realizados reali zados além do planejado e funcionalidades aquém das expectativas. Esses problemas, embora considerados inerentes ao desenvolvimento de software por muitos autores, podem podem ser minimizados mi nimizados e controladoss pelo contínuo gerenciamento de risco em projetos. trolado O tempo de reação aos riscos é um fator preponderante para a economia, como pode ser visto na Figura 2. A reação imediata, feita no momento da identificação e da análise dos riscos, na fase inicial, é chamada de reação de prevenção, e acontece antes da decisão final fi nal sobre o projeto, alterando as principais variáveis de impacto no projeto, como escopo, qualidade, tempo ou condições financeiras. O quanto antes ocorrerem a identificação, prevenção e contingência relacionadas aos riscos, menores serão os custos de impacto ao projeto. Em contraposição, a estimativa de custo do projeto possui maior nível de acerto com o passar do tempo. A Figura 3 é conhecida como Cone de incerteza, sua leitura mostra que, no início do projeto, a estimativa possui maior taxa de erro. Estimativas realizadas na fase conceitual podem ter um erro de quatro vezes, ou um-quarto do valor estimado; o erro se reduz com o aumento do conhe cimento sobre o projeto. Edição 69 - Engenharia de Software Magazine
19
Figura 1. Visão geral do gerenciamento de riscos do projeto
Figura 2. Momento da reação diante dos riscos
A figura apresenta de modo simples um direcionamento do melhor momento para a determinação do custo real do projeto, embora seja compreensível que o erro decresce com o tempo, esse gráfico não leva em consideração a nece ssidade do cliente em saber o mais rápido possível o valor do projeto. Essa distância entre a assertividade e os interesses do mercado, é que fazem surgir diversos riscos, e também indicam momentos em que decisões precisam ser tomadas.
20
Figura 3. Cone de incerteza, melhoria da estimativa de custo ao longo do
tempo
Riscos podem ser considerados positivos ou negativos. Alguns são oportunidades gerenciais, assim, encontrar essas oportunidades e maximizar seus efeitos gera uma vantagem ao gerente. Por exemplo, em uma equipe pequena de
Engenharia de Software Magazine - Riscos em projetos de software com PMBOK
PLANEJAMENTO
desenvolvimento acarreta riscos a saída de um desenvolvedor, com grande impacto negativo no projeto mas, em contrapartida, uma equipe desse tamanho é mais fácil de ser alinhada, gerenciada e treinada; nessa situação cabe o gerenciamento otimista para manter a equipe motivada e coibir saídas de colaboradores. Autores
Fatores de Risco
a
B
c
d
1. Mudança de Escopo/objetivos
X
X
X
X
2. Falta de envolvimento adequado dos usuários
X
X
X
3. Requisitos mal entendidos e/ou mal definidos
X
X
X
4. Escopo/objetivos pouco claros ou equivocados
X
X
X
5. Prazos e tempo para tarefas mal estimados
X
X
X
6. Gerenciamento impróprio de mudanças
X
X
X
7. Volatilidade nos requisitos (falta de requisitos estáticos)
X
X
X
8. Custos mal estimados
X
X
X
9.Falta de poderes para o gerenciamento de projetos
X
10. Conflito entre departamentos de usuário
X
X
11. Falh a em gerencia r as expectativas finais dos usuários
X
X
12. Planejamento inexistente ou inadequado
X
X
13. Pessoal envolvido insuficiente/inapropriado
X
X
X
X
14. Falta de conhecimento/competência dos envolvidos no projeto
X
X
X
X
15. Falta de Cooperação dos usuários
X
X
X
16. Falta de metodologia efetiva em gerenciamento de projetos
X
X
17. Controle pobre ou inexistente
X
X
18. Adoção de novo método/tecnologia
X
X
19. Falha em obter comprometimento do cliente
X
X
20. Definição imprópria de papéis e responsabilidades
X
X
21. Falta de comprometimento da alta gerência
X
X
22. Falta de motivação da equipe
X
23. Falt a de habilidade para o gerenciamento de projetos
X
X
24. Assunto novo ou não familiar
X
X
Riscos no desenvolvimento de software A seguir é apresentada uma lista de riscos que impactam o desenvolvimento de soft ware. Na Tabela 1 são listados trinta e três fatores de risco, organizados por ordem de relevância. Essa lista é um trabalho exploratório com gerentes de projeto de software de diversas localidades no Brasil e em Hong Kong, Finlândia e Estados Unidos da América.
Grupos de fatores de risco A partir dos riscos listados na Tabela 1 , é possível observar que alguns possuem impactos semelhantes nos projetos de software como, por exemplo, mudança de escopo/objetivos; escopo/objetivos pouco claros ou equivocados; requisitos mal entendidos e/ou mal definidos; volatilidade nos requisitos (falta de requisitos estáticos). Na Tabela 2 é apresentada uma comparação entre diferentes grupos de fatores de risco. Grupo 1
Grupo 2
Novidade Tecnológica
25. Mudança no proprietário do projeto ou na alta gerência
X
26. Rotatividade da equipe
X
27. Projeto com múltiplos fornecedores
X
28. Usar nova metodologia de desenvolvimento em projetos importantes
X
X
X
X
30. Sistema complexo
X
31. Tarefas complexas
X
32. Falta de tecnologias maduras/existentes
X
33. Deficiência de execução em tempo real Tabela 1. Levantamento dos fatores de r isco do desenvolvimento de
Tecnologia
Complexidade da Aplicação Requisitos Tamanho da Aplicação Escopo Habilidades da Equipe Expertise Pessoas Gestão de Projetos Financiamento Processo de desenvolvimento Planejamento Programação/ Agendamento Patrocínio/Propriedade Gestão de Relacionamentos
X
29. O sistema possui integração e interface com outros sistemas
software
Existem diversos riscos negativos no desenvolvimento de software. Estudos mostram que 25% dos sistemas de software de larga escala em desenvolvimento são cancelados. Em média, projetos ultrapassam o prazo de desenvolvimento em mais da metade do tempo planejado, projetos ma iores geralmente são piores. Apenas 25% dos projetos de larga escala não são considerados “falhas operacionais”, os outros 75%, ou não funcionam como previsto ou não são usados na íntegra.
X
X X
Ambiente Organizacional
Ambiente Corporativo
-
Dependências externas
Grupo 3
Conhecimento e incerteza tecnológica Escopo e Requisitos Equipe de desenvolvimento
Gestão de projetos
Relacionamento com cliente e usuário Valor/importância atribuído ao projeto Relacionamento com o ambiente externo
Tabela 2. Tabela comparativa entre os grupos de riscos propostos na
literatura
Tomando por base os dados apresentados na tabela anterior , é proposta uma nova lista de grupos de fatores de risco. Esses conjuntos foram propostos para um melhor entendimento acerca dos riscos. Segmentar os riscos em grupos facilita o entendimento do gerente de projetos sobre o contexto de cada risco. Os seis grupos propostos são: Edição 69 - Engenharia de Software Magazine
21
• Gestão de Dependências:
relaciona-se com os riscos que envolvem qualquer tipo de dependência, seja direta ou indireta com o software ou o projeto. As dependências podem ser com relação a tecnologia, pessoas, fornecedor, outros sistemas, etc.; • Gestão de Escopos e Requisitos: todos os riscos que envolvem os escopos e os requisitos do projeto serão tratados nesse grupo; 1. Gestão de Dependências
1.1. Gerenciamento impróprio de mudanças. 1.2. Falha em gerenciar as expectativas finais dos usuários. 1.3. O sistema possui integração e interface com outros sistemas. 1.4. Mudança no proprietário do projeto ou na alta gerência. 1.5. Projeto com múltiplos fornecedores. 1.6. Sistemas complexos. 2. Gestão de Escopo e Requisito 2.1. Mudança de Escopo/objetivos. 2.2. Requisitos mal entendidos e/ou mal definidos. 2.3. Volatilidade nos requisitos (falta de requisitos estáticos). 2.4. Escopo/objetivos pouco claros ou equivocados. 3. Gestão de Inovação e Tecnologias 3.1. Adoção de novo método/tecnologia. 3.2. Assunto novo ou não famili ar. 3.3. Usar nova metodologia de desenvolvimento em projetos importantes. 3.4. Falta de tecnologias maduras/existentes. 3.5. Deficiência de execução em tempo real. 4. Gestão de Pessoas 4.1. Pessoal envolvido insuficiente/inapropriado. 4.2. Falta de conhecimento/competência dos envolvidos no projeto. 4.3. Falta de habilidade para o gerenciamento de projetos. 4.4. Falta de motivação da equipe. 4.5. Rotatividade da equipe. 5. Gestão de Projetos 5.1. Prazos e tempo para tarefas mal estimados. 5.2. Custos mal estimados. 5.3. Planejamento inexistente ou inadequado. 5.4. Falta de metodologia efetiva em gerenciamento de projetos. 5.5. Controle pobre ou inexistente. 5.6. Definição imprópria de papéis e responsabilidades. 5.7. Tarefas complexas. 6. Gestão de Relacionamentos 6.1. Falta de envolvimento adequado dos usuários. 6.2. Falta de comprometimento da alta gerência. 6.3. Falta de Cooperação dos usuários. 6.4. Conflito entre departamentos de usuário. 6.5. Falha em obter comprometimento do cl iente. 6.6. Falta de poderes para o gerenciamento de projetos. Tabela 3. Grupos propostos dos fatores de risco avaliados e selecionados
da literatura
22
• Gestão de I novação e Tecnologias: é o grupo destinado
a lidar com as escolhas tomadas acerca das tecnologias e inovações; • Gestão de Pessoas: são todos os fatores que envolverem pessoas no que tange conhecimentos, habilidades, capacidades, motivação etc.; • Gestão de Projetos: atributos comuns do gerenciamento como prazo, custo, esforço e outros, são inseridos nesse grupo; • Gestão de Relacionamentos: aqui envolvem todos os riscos atribuídos ao relacionamento entre os envolvidos no projeto, sejam pessoas internas ou externas.
Fatores de risco no desenvolvimento de software Nas seções anteriores foram realizados o mapeamento e análise dos fatores de risco de maior impacto no desenvolvimento de software. Em seguida, esses fatores foram agrupados por contexto. Os trinta e três fatores de risco foram distribuídos nos grupos anteriormente definidos. Para a avaliação dos riscos, segmentá-los em grupos facilita a compreensão do contexto, ter os riscos distribuídos em blocos de mesmo assunto foi importante para a realização do trabalho. No próximo tópico será abordada a criação de modelos e utilização desses para a realização de simulações. A Tabela 3 apresenta os grupos e seus respectivos riscos associados. Os riscos presentes em cada grupo estão organizados pela ordem de impacto. O primeiro item de cada grupo é o risco mais impactante daquele contexto e assim sucessivamente. A Tabela 3 apresenta os grupos sugeridos com os respectivos riscos. Como dito anteriormente, esses grupos representam contextos e esses contextos foram utilizados para simular a dinâmica entre os riscos.
Dinâmica entre riscos O mundo é composto por variáveis e essas estão prese ntes em todos os ciclos dos processos dos homens e da natureza. O pensamento sistêmico é um conjunto de conhec imentos e ferramentas desenvolvido nos últimos cinquenta anos que visa nos auxiliar a recon hecer padrões e fornecer mecanismos para modificá-los efetivamente. Ele é livre, não possui uma tecnologia associada obrigatória e tem como objetivo enxergar o todo, observar padrões, estruturas, conexões e realizar uma reestruturação das inter-relações de forma mais harmoniosa. É possível conectar variáveis e analisar suas interferências através de um diagrama de causalidade. Os diagramas de causalidade, também conhecidos como diagramas de influência, constituem a ferramenta principal do pensamento sistêmico. De acordo com esta visão, o mundo opera em circuitos de ret roalimentação de reforço e balanceamento. O movimento desses ciclos em conjunto é considerado o comportamento geral do fenômeno ou evento sendo investigado. Na Figura 4 pode ser visto um exemplo de diagrama de causalidade.
Engenharia de Software Magazine - Riscos em projetos de software com PMBOK
PLANEJAMENTO
Figura 4. Esta figura é um exemplo de diagrama de causalidade
Os símbolos “+ e -”, simbolizam que, quando se altera determinada variável, essa causa u m impacto na variável adjacente (ligada a ela) no mesmo sentido (sinal de mais) ou em sentido oposto (sinal de menos). Na modelagem anterior, quando se aumenta solução sintomática, seta com “+”, aumenta-se o efeito de consequências não-intencionais e diminui-se, seta com “-”, sintoma do problema. As consequências não-intencionais quando crescem, aumentam os efeitos de sintoma do problema. O arco cortado por duas linhas paralelas tem o significado de que o efeito produzido não é imediato, ou seja, demanda u m tempo até ocorrer, possui um “delay”. As letras “R” e “E” significam, respectivamente, que o caminho fechado tende a um reforço ou equilíbrio, ou seja, sintoma do problema estimula solução sintomática e solução sintomática desestimula sintoma do problema, com isso tem-se um equilíbrio entre eles. A Figura 5 apresenta um exemplo de diagrama de causalidade utilizando as variáveis de risco citadas neste artigo.
Figura 5. Esta figura é um exemplo de diagrama de causalidade no
desenvolvimento de software
Saindo dos detalhes da ferramenta e observando as relações entre os itens do diagrama, pode-se produzir várias inferências. Primeiramente, para facilitar o entendimento, cada variável considerada será explicada: • Capacidade produtiva: é a capacidade de produzir o projeto, no caso, pode ser entendido como sendo a quantidade de pontos de função que são produzidos; • Soft ware desenvolvido: é a quantidade de software que já foi produzido; • Tempo de entrega: esse item se refere ao tempo gasto para desenvolver o projeto, ou seja, o tempo que é gasto para que o software esteja completamente desenvolvido; • Erro: quantidade de erro produzido; • Retrabalho: quantidade de retrabalho que é gerado a partir dos erros. Pode ser iniciada uma leitura do diagrama a partir de qualquer item, por exemplo tomando como ponto inicial a capacidade produtiva , quanto mais código é produzido, tem-se mais software desenvolvido , e maior é a quantidade de erro gerado, em consequência cresce também a quantidade de retrabalho que a equipe terá que realizar e, com isso, menos software desenvolvido , uma vez que retrabalho é refazer algo que a princípio já estava pronto. A quantidade de software produzido é afetada tanto pela capacidade produtiva quanto pelo retrabalho , e por sua vez, ele impacta o tempo de entrega , que significa o tempo necessário para entregar o projeto, ou seja, se existe muito software pronto, precisa-se de menos tempo para entregá-lo, de outro modo, se o desenvolvimento não foi satisfatório o prazo de entrega cresce. O tempo de entrega afeta diretamente a capacidade produtiva , quanto mais tempo é gasto desenvolvendo algo, cresce também o conhecimento da equipe, tanto na tecnologia utilizada para desenvolver o projeto, quanto no projeto em si, com isso, a produção aumenta. Uma nota importante: por mais que a produção aumente com o passar do tempo, esse fator não infere em um crescimento constante, a tendência é um aumento produtivo nos primeiros meses e posteriormente uma estabilidade, sendo assim, tem-se um estado de equilíbrio com o tempo. Esse equilíbrio pode ser quebrado aumentando a equipe, melhorando os treinamentos, técnicas motivacionais e outros. Esses f atores podem ser testados a partir de simulações, diagramas de causa lidade são convertidos em diagramas matemáticos que suportam simulações de cenários. A simulação é a avaliação numérica de um modelo matemático que descreve um sistema. Muitos sistemas são muito complexos para soluções analíticas fechadas, ou seja, planilhas, fluxogramas, entre outros. Portanto, a simulação é usada para exercitar modelos com entradas dadas para ver como o sistema executa. Existem diversas técnicas para realizar simulações com variáveis dinâmicas. Uma dessas é conhecida como Dinâmica de Sistemas – DS. Com a DS é possível analisar o comportamento dinâmico dos riscos. Utilizando os contextos dos grupos de riscos listados neste artigo, foram realizadas análises com base em simulações. Edição 69 - Engenharia de Software Magazine
23
Para validar e produzir valores iniciais para as simulações, foram utilizados os dados de uma pesquisa que adquiriu uma base de dados de projetos de software do Grupo Internacional de Padrões de Benchmarking em Software ( International Software Benchmarking Standards Group - ISBSG). Na Tabela 4 podem ser vistas algumas das informações. Variáveis
Média
Mínimo
Máximo
Pontos de Função – PF
521,04 PF
11
9803
Esforço
5217,7 homem-horas
17,0
150.040,0
Tamanho da Equipe
8 pessoas
1
77
atribuídos aos três projetos de tamanhos diferentes os mesmos valores nos fatores de risco, permanecendo intacto somente o tamanho do projeto e tamanho da equipe. A intenção dessa abordagem é apresentar o impacto da variação dos fatores de risco na mudança do tamanho do projeto, e o que ocorreria, se os projetos tivessem atributos de risco iguais. O primeiro retângulo da esquerda para a direita representa um projeto pequeno, o segundo um projeto médio e o terceiro um projeto grande. No caso 1, os prazos de desenvolvimento respectivamente foram: três, cinco e quatorze meses; no caso 2: três, dois e quatro. Essa sequência é mantida para os dois exemplos: “Caso 1” e “Caso 2”.
Tabela 4. Pontos de Função – PF (ver BOX 2) BOX 2. Análise de Pontos de Função
Análise de Pontos de Função – APF, é uma técnica que visa medir o tamanho funcional de um software, para, a partir desses dados, oferecer mecanismos para estimar esforço, prazo e custo. Na edição de número 44 da Engenharia de Software Magazine é possível ter uma visão geral acerca dessa técnica. Na tabela o esforço é dado na unidade de homem-horas, uma medida que significa a quantidade de horas que um homem teria que trabalhar para realizar o projeto. Tamanho da equipe é o número de pessoas envolvidas na realização do projeto.
Além desses dados, foram obtidos com uma microempresa de software que utiliza a métrica em pontos de função, os dados de um projeto da empresa. Para um projeto de duzentos e setenta pontos de função realizado por uma equipe de três pessoas, foi fornecida a informação de que a empresa gasta o prazo de três meses para o desenvolvimento. Com esses números em mãos, foi possível validar os testes. Na Tabela 5 podem ser vistos os valores dos fatores de risco com os respectivos tamanhos dos projetos. Tamanho Aproximado dos Projetos
Tamanho da equipe Prazo de desenvolvimento Conhecimento inicial sobre linguagem e projeto Porcentagem de erros encontrados Porcentagem de erros eliminados com teste Porcentagem de retrabalho Porcentagem de apoio do cliente
270 PF
520 PF
3 pessoas 3 meses Alto 30% 20% 24% 95%
8 pessoas 5 meses Médio 50% 20% 40% 90%
9800 PF
77 pessoas 14 meses Baixo 63% 20% 50,4% 75%
Tabela 5. Variação de alguns fatores de risco para cada tamanho de
projeto de software
A seguir, uma discussão sobre os dados apresentados na tabela é apresentada. Alguns dos valores representados na Tabela 5 foram retirados da literatura, outros foram obtidos através de ajustes. Os ajustes realizados demonstram a existência do impacto dos riscos no tamanho dos projetos de software. A Figura 6 apresenta dois casos. No primeiro caso, foram realizadas simulações com os dados presentes na tabela anterior. Como pode ser visto, cada projeto possui características diferentes como, por exemplo, a porcentagem de erros encontrados , porcentagem de apoio do cliente, e outros. No segundo caso, foram
24
Figura 6. Impacto da variação dos fatores de risco
Com as informações apresentadas , pode ser observado que se os impactos dos riscos fossem mantidos em qualquer taman ho de projeto, a dificuldade em executar um projeto grande ou pequeno seria praticamente a mesma. Os dados presentes na figura e nas tabelas anteriores fornecem informações valiosas, que serão tratadas a seguir. Algumas das variáveis apresentadas tiveram seus valores retirados da literatura, essas foram: tamanho aproximado dos projetos , tamanho da equipe , prazo de de senvolvime nto e porce ntagem de retrabalho. As demais variáveis foram ajustadas com as simulações e utilizaram os seguintes parâmetros para ajustes, a quantidade de pessoas necessárias ( tamanho da equipe) para realizar um projeto de um determinado tamanho (tamanho do projeto) em um prazo determinado ( prazo de desenvolvimento). Cerca de 80% do sucesso do projeto está relacionado com 20% do esforço (seguindo a conhecida relação “regra de Pareto”), aproximadamente 80% dos erros estão em 20% dos módulos do projeto. Para lidar com os valores médios de retrabalho, sem diferenciar a qualidade da equipe que executa o projeto, definiu-se um valor padrão para a capacidade de correções de erros (i.e., 20%). Como o retrabalho ocorre para corrigir os erros que não foram capturados, foi observado que a quantidade de erros realmente cresce com o aumento do tamanho do projeto. Caso não houvesse o aumento do número de erros com a elevação do tamanho do projeto, o prazo de desenvolvimento seria reduzido, como pode ser visto na Figura 7.
Engenharia de Software Magazine - Riscos em projetos de software com PMBOK
PLANEJAMENTO
dados estimados. O tamanho da equipe no projeto pequeno se manteve e com isso o prazo também ficou igual, no projeto de tamanho médio houve uma redução de duas pessoas e um aumento de um mês no prazo de desenvolvimento e no projeto de larga escala, houve um aumento de trinta e uma p essoas na equipe e uma redução de dois meses no desenvolvimento. Tamanho Aproximado dos Projetos 270 PF
Figura 7. Queda no prazo de desenvolvimento com a redução da
520 PF
9800 PF
Tamanho Equipe (a)
3 pessoas
8 pessoas
77 pessoas
Prazo de Desenvolvimento (a) Tamanho Equipe (b) Prazo de Desenvolvimento (b)
3 meses 3 Pessoas 3 meses
5 meses 6 pessoas 6 meses
14 meses 108 pessoas 12 meses
Tabela 6. Dados reais X Dados estimados
porcentagem de retrabalho
A figura apresenta o impacto do retrabalho em um projeto. De acordo com a literatura, em torno de 40% a 50% do esforço no desenvolvimento de software é gasto em retrabalho. Esses dados mostram como o retrabalho está altamente ligado ao desenvolvimento de software, por mais que a redução do retrabalho a zero não seja uma realidade, a Figura 7 expõe como a redução desse fator pode diminuir o prazo de desenvolvimento e fortalece a relevância da realização de testes e uma ótima análise de requisitos, para capturar e impedir erros no software. Outras duas variáveis muito importantes esti madas com as simulações foram: conhecimento inicial sobre a linguagem e o projeto; porcentagem de apoio do cliente. Quanto maior a equipe de trabalho, ter um conhecimento inicial intensifica a produtividade ( conhecimento inicial sobre a linguagem e o projeto); com as simulações foi observado que, com um conhecimento médio acerca de um projeto amplo, pode-se reduzir em até 25% o prazo de desenvolvimento, mas juntamente com o tamanho do projeto, cresce também a dificuldade em possuir um conhecimento inicial. Embora essa dificuldade exista, ela não exclui a possibilidade de utilizar um conhecimento inicial maior, para aumentar a produtividade. O suporte do cliente ( porcentagem de apoio do cliente) não aumenta a produtividade, mas reduz possíveis atrasos, uma vez que cabe ao cliente aprovar as etapas do desenvolvimento. Se em alguma etapa o cliente atrasar para confirmar algum requisito, o projeto é afetado. Durante a pesquisa foi captu rado o risco da falta de apoio do cliente , o qual impactava apenas quando não havia o suporte dos clientes. Nos projetos maiores foi necessário diminuir a porcentagem do apoio do cliente nas simulações. Uma conclusão importante, não é que os c lientes ficam menos solícitos em grandes projetos, mas que o número de processos que deverão ser aprovados aumenta, e com isso aumenta o risco de o cliente falhar com o suporte necessário. Após o modelo ter sido ajustado, foi possível estimar um tamanho médio de equipe por tamanho de projeto de software em ponto função. Com essa informação é possibilitado ao gerente saber quantas pessoas ele necessita para realizar um projeto. Os valores estimados foram colocados em comparação com dados reais na Tabela 6. Sendo (a) os dados reais e (b) os
O valor estimado são de noventa pontos função por pessoa. Esse valor foi estimado a partir da média entre a menor produtividade por pessoa, quinhentos e vinte dividido por oito (sessenta e cinco) e a maior produtividade, nove mil e oitocentos dividido por setenta e sete (cento e vinte e sete). O valor obtido foi de noventa e seis, o qual foi ajustado para noventa pontos função utilizando as simulações. A fórmula a seguir foi gerada a partir das simulações realizadas para este trabalho e apresenta um cálculo simples que o gerente pode fazer para estimar a equipe: tamanho equipe = tamanho projeto (PF) / 90 (PF)
Essa fórmula pode ser usada para estimar o tamanho da equipe quando o gerente não possui um histórico de desenvolvimento, no caso de haver histórico, o ideal é seguir a capacidade produtiva da equipe. O erro da fórmula cresce com o au mento de tamanho do projeto, como pode ser observado na Tabela 6. Cada equipe e projeto possuem características intrínsecas, mas esses atributos não diminuem a utilização de fórmulas para estimar dados que auxiliam nas tomadas de decisões. Cabe ao gerente de projetos avaliar e criar mecan ismos para lidar com esses resultados obtidos.
Processo de qualidade e risco calculado É necessário medir o preço que se paga por não realizar gerenciamento de riscos. Na maioria dos casos ess es preços vão além de fatores financeiros, estão também relacionados com orgulho, prestígio, reputação, relacionamentos e outros. Durante a pesquisa, foi observado que normalmente os gerentes de projetos visualizam a necessidade do gerenciamento de riscos somente em projetos de larga escala, riscos são vistos como algo extra e não como uma tarefa prioritária em projetos menores. A Melhoria de Processo do Software Brasileiro - MPS.BR fornece um conhecimento acerca do gerenciamento de riscos, e essa gestão pode ser realizada por empresas pequenas e em crescimento. O MPS.BR possui um nível de maturidade (i.e., nível C) que exige lidar completamente com o gerenciamento de riscos, mas já no nível G, nível inicial do programa de Edição 69 - Engenharia de Software Magazine
25
qualidade, é requerido a utilização de mecanismos simples para lidar com os riscos. O nível parcialmente gerenciado (i.e., nível G) do guia geral MPS.BR, possui como resultados esperados os seguintes itens relativos a identificação e gerenciamento de riscos: os riscos do
variação no tamanho da equipe em 50%, a Figura 8 apresenta os resultados obtidos no prazo de desenvolvimento.
projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados; os riscos são monitorados em relação ao planejado. Esses itens articulam
ações iniciais na análise e gerenciamento de riscos.
Apoio à tomada de decisão A tomada de decisão é envolvida por problemas classificados em: estruturados, semi-estruturados e não-estruturados (desestruturados). Estruturados são aqueles que podem ser completamente determinados, porque possuem soluções amplamente conhecidas. Para lidar com problemas estrut urados, é possível utilizar listas predefinidas como, por exemplo, ações operacionais padronizadas, em que qualquer funcionário ou máquina pode tomar decisões seguindo um fluxograma. Semiestruturados estão em uma posição intermediária, possuem interseções com problemas estruturados, mas alguns pontos do problema não são bem conhecidos. São desafios que necessitam de um nível médio de julgamento humano e experiência para serem solucionados. Já problemas desestruturados, são mais complexos, porque ocorrem ocasionalmente, suas estruturas não são bem definidas e exigem maior julgamento e experiência para solucioná-los. Ou seja, não existem soluções prontas para esse tipo de problema; experiências acumuladas com problemas similares, conhecimentos e ferramentas de apoio à decisão são utilizadas para esse tipo de desafio. O gerente de projetos precisa descobrir quais tipos de desafios está enfrentando. Modelos, tabelas e planilhas são ótimas ferramentas para problemas estruturados, para os demais não é possível usar ferramentas que forneçam soluções diretas. São necessárias tecnologias que auxiliem à tomada de decisão, como sistemas de apoio à decisão, simuladores, modelos dinâmicos entre outros. O impacto mais óbvio da utilização de ferramentas de apoio à decisão é a melhoria da tomada de decisão. Informações e ferramentas de apoio à decisão podem trazer diversos benefícios: fornecer uma visão dos diversos cenários possíveis; munir os gerentes de alternativas para lidar com os riscos do projeto; aumentar a confiança nas tomadas de decisões; por fim e não menos importante, intensificar a velocidade com que as decisões são tomadas. Nesta parte do artigo serão apresentados cenários de desafios que o gerente de projetos de software pode enfrentar. Foram realizadas diversas simulações e comparações, a fim de que esses cenários auxiliem o gerente nas tomadas de decisões. Foi utilizado como cenário base, o projeto de médio porte (i.e., 520 PF) descrito na Tabela 5 , e levou-se em consideração todos os valores dos atributos listados na tabela para o projeto desse porte. Um desafio comum de um gerente de projetos é o tamanho da equipe à sua disposição. Foram geradas simulações com uma
26
Figura 8. Variação no prazo provocado a partir da alteração do tamanho
de uma equipe em um projeto de quinhentos e vinte pontos função
A figura apresenta uma visão do prazo de desenvolvimento considerando equipes com capacidades produtivas idênticas. Para os três casos apresentados anteriormente, o único fator que foi alterado nas simulações de um caso para outro, foi o tamanho da equipe, todos os demais dados foram mantidos, com isso é possível comparar o efeito de alterar o tama nho da equipe. Com as simulações foi observado que reduzir a equipe em 50% gerou mais impacto do que aumentá-la na mesma proporção, essa diferença será discutida juntamente com os dados da Figura 9. No cenário anterior, as equipes possuíam um conhecimento médio sobre a linguagem e o projeto. Na Figura 9 é exposta uma comparação entre os tamanhos das equipes variando também o nível de conhecimento. A variação do conhecimento foi de 60% para mais e para menos, variando-o de baixo a alto, passando por médio.
Figura 9. Impacto no prazo gerado pela variação do conhecimento em
equipes de desenvolvimento de software. Dados gerados a partir de simulações
Podemos observar que o conhecimento gera maior resultado na menor equipe, a diferença entre o pior caso e o melhor
Engenharia de Software Magazine - Riscos em projetos de software com PMBOK
PLANEJAMENTO
nessa equipe, são de seis meses. Uma equipe menor bem treinada consegue ter um rendimento melhor ou igual a uma equipe de taman ho três vezes maior com conhecimento baixo ou médio. O impacto do conhecimento não é linear, ou seja, ele não decresce ou aumenta na mesma proporção nos três ca sos, isto é, nas equipes de quatro, oito e doze pessoas. Quanto maior o número de pessoas, a comunicação interna acaba sendo reduzida e os conflitos aumentados. Esses são alguns dos fatores que não permitem que a expressão do conhecimento dos desenvolvedores, sejam iguais independente da quantidade de pessoas envolvidas. Na próxima análise o tamanho do projeto será o foco, foi mantida a variação do tamanho da equipe em 50% para mais e menos, nas simulações o conhecimento inicial foi deixado médio para todas as equipes. Na Figura 10 é apresentado como o prazo de desenvolvimento de cada equipe variou reduzindo e aumentando o tamanho do projeto em 50%. A Figura 10 gera alguns questionamentos. Avaliando o comportamento do gráfico, fica nítido o impacto do tamanho do projeto em cada equipe, o questionamento gira em torno do motivo de o comportamento ser diferente. Nos projetos de quatro e oito pessoas, a diferença entre o projeto menor com o médio é de dois meses e, para a equipe de doze pessoas, a diferença é de apenas um mês. Nas equações utilizadas para realizar as simulações, quanto mais tempo uma equipe passa desenvolvendo um projeto, melhor ela fica, uma vez que o conhecimento aumenta com o passar do tempo, projetos maiores dão mais tempo para a equipe melhorar e aumentar o alinhamento entre seus integrantes.
Figura 10. Impacto da variação do tamanho do projeto no prazo de
desenvolvimento. Dados gerados a par tir de simulações
Veja que foi levantada no parágrafo anterior a questão da equipe de doze pessoas reduzir apenas um mês do projeto médio para o menor, e quando compara-se o prazo de desenvolvimento dela com a equipe de oito desenvolvedores, o prazo do projeto de duzentos e sessenta pontos função é igual. As simulações deixam claro que aumentar o tamanho da equipe nem sempre é uma vantagem de produção. Sendo assim, o gerente precisa tomar cuidado para não colocar menos pessoas que o necessário para realizar um projeto e nem ultrapassar demais o valor ideal. Em um dos casos da Figura 10 isso ocorreu, doze desenvolvedores para realizar um projeto de duzentos e sessenta pontos função mostrou-se uma decisão ruim, o número de processos concorrentes em projetos
Edição 69 - Engenharia de Software Magazine
27
pequenos são poucos, isso faz com que em certos momentos desenvolvedores fiquem ociosos. Para fim de conhecimento, para reduzir mais um mês no projeto de duzentos e sessenta pontos função, foi necessário nas simulações colocar uma equipe de quinze pessoas, uma equipe desse tamanho apresenta-
Figura 11. Impacto gerado no prazo, a partir da variação do
conhecimento da equipe de desenvolvimento, em projetos de duzentos e sessenta pontos função
Figura 12. Impacto gerado no prazo, a partir da variação do
conhecimento da equipe de desenvolvimento, em projetos de quinhentos e vinte pontos função
se inviável para um projeto desse porte, principalmente por questões orçamentárias. A seguir, serão apresentadas as Figuras 11 a 13 , que representam o impacto da variação do conhecimento em cada tamanho de projeto de software, os dados foram gerados com simulações, cada barra do gráfico representa respectivamente conhecimento baixo, médio e alto. Na discussão da Figura 10 questionou-se o fato de um grupo de oito e doze desenvolvedores obterem o mesmo desempenho para um projeto de duzentos e sessenta pontos função. Observando a Figura 11 , pode ser visto que essas equipes continuam obtendo resultados semelhantes mesmo quando se aumenta o conhecimento de ambas. Todavia, quando o projeto aumenta de tamanho, os resultados não permanecem iguais, principalmente pelo já citado argumento de que projetos maiores oferecem mais tempo para os desenvolvedores se aperfeiçoarem e, quanto mais desenvolvedores, mais pessoas estão se aperfeiçoando. Observando os dados apresentados, pode-se concluir que uma equipe pequena competente e bem treinada, em projetos pequenos e médios, consegue obter resultados satisfatórios quando comparados com uma equipe três vezes maior e de mesma competência. Ter uma equipe menor e qualificada mostrou-se, em alguns dos casos, uma decisão melhor do que optar por uma equipe ampla. Para finalizar esta seção, será apresentado um gráfico que representa o ponto de equilíbrio entre os gráficos dos custos aqui apresentados. O ponto de equilí brio (do inglês, break even point) é o ponto onde o cone de incerteza ( Figura 3) intercepta o momento da reação diante dos riscos ( Figura 2). Considerando que o comportamento dos dois gráficos sejam igua is, o ponto de equilíbrio fornece o momento em que não vale mais a pena esperar para estimar o custo e o ponto final para reagir diante dos riscos. Avaliando a Figura 14 fica claro que não vale a pena realizar estimativas de custo após o ponto de cru zamento, porque é o momento em que fica mais caro o preço que se paga por reagir tarde demais aos riscos. A decisão do gerente sobre os custos do projeto deve ocorrer entre o fim da fase inicial e o início da fase intermediária do desenvolvimento.
Figura 14. Momento do ponto de equilíbrio entre o cone de incerteza e
momento de reação diante dos riscos
Figura 13. Impacto gerado no prazo, a partir da variação do
conhecimento da equipe de desenvolvimento, em projetos de setecentos e oitenta pontos função
28
As informações apresentadas nessa seção foram organizadas para prover aos gerentes de softwares, conhecimentos que possam lhes auxiliar nas tomadas de decisões de projetos de softwares.
Engenharia de Software Magazine - Riscos em projetos de software com PMBOK
PLANEJAMENTO
Como foi visto, os trinta e três fatores de risco agrupados em seis conjuntos, formam uma base de conhecimento para o gerente de projetos, que pode usar dessa ferramenta para auxiliar em suas decisões. Além dessa base, é apresentada uma tabela comparativa entre projetos de pequeno, médio e grande porte e resultados gerados a partir de simulações para fornecer aos gerentes de projetos de software, conhecimentos para lhes auxiliar nas tomadas de decisões. No gerenciamento de riscos deseja-se diminuir as incertezas. Esse processo pode ser elaborado com um grande planejamento de ações para lidar com cada situação adversa, ou pode ser algo simples como, por exemplo, ter conhecimento dos problemas que podem atrapalhar o fluxo desejado do projeto. Gerenciar risco não é uma tarefa que deve ser executada apenas em grandes projetos, mas sim uma atividade que deve ser incorporada ao cotidiano do gerenciamento de projetos. Existem inúmeros outros instrumentos que auxiliam na análise e gerenciamento dos riscos, uma dessas outras ferramentas, a qual os resultados foram apresentados no artigo, é o uso de simulações para estimar o impacto e relacionamento entre os fatores de risco. Este artigo não visa ser um arcabouço completo de conhecimento sobre o tema, mas sim uma estrutura in icial para pesquisas posteriores sobre o assunto.
Links: 1. Barki, H., Rivard, S., Talbot, J.: Toward an Assessment of Software Development Risk, J. Management Information Systems, Vol. 10, No. 2, pp. 203-225 (1993) 2. Boehm, B. W.: Software Engineering Economics, IEEE Transactions on Software Engineering, Vol. SE-10, No. 1, January, pp. 4-21 (1984) 3. Boehm, B. W.: Software Risk Management: principles and practices, IEEE Software, Vol. 8, No. 1, pp. 32-40 (1991) 4. Charette, R.N.: Software Engineering Risk Analysis and Management. McGraw-Hill, New York (1989) 5. Leopoldino, C. B. Avaliação de Risco em Desenvolvimento de Software. Dissertação de Mestrado – Escola de Administração do Rio Grande do Sul, Porto Alegre (2004) 6. Madachy, R.: Software Process Dynamics, Wiley-IEEE Press, Washington D.C. (2007) 7. Schimidt, R., Lyytinen, K ., Keil, M., Cule, P.: Identifying Software Project Risks: An International Delphi Study. Journal of Management Information System. Vol. 17, No. 4, pp. 5-36 (2001)
Você gostou deste artigo? Dê seu voto em www.devmedia.com.br/esmag/feedback Ajude-nos a manter a qualidade da revista!
Edição 69 - Engenharia de Software Magazine
29
Planejamento e Gerência Nesta seção você encontra artigos voltados para o planejamento e gerência de seus projetos de software.
Gerência de Projetos: Monitore e controle o desenvolvimento de software
A Rommel Gabriel Gonçalves Ramos Possui Graduação em Administração de Sistemas de Informação pelo Centro Universitário Una (2004).Pós-graduação (especialização) em Melhoria de Processo de Software pela Universidade Federal de Lavras (2007). Mestrado em Tecnologias da Inteligência e Design Digital (TIDD) na PUC/SP.(2013).Atualmente e Consultor de TI na Caixa Econômica Federal. Professor do SENAC/SP do Curso de Pós-Graduação (Especialização) em Gestão e Governança de Tecnologia da Informação).
Daniel Couto Gatti Possui graduação em Ciência da Computação pela Pontifícia Universidade Católica de São Paulo (1995), Mestrado em Comunicação e Semiótica pela Pontifícia Universidade Católica de São Paulo (2002) e Doutorado em Educação Matemática pela Pontifícia Universidade Católica de São Paulo (2009). Atualmente é Diretor da Faculdade de Ciências Exatas e Tecnologia da PUC/SP, professor da Faculdade de Tecnologia Bandeirantes, professor titular do Instituto Brasileiro de Tecnologia Avançada e assistente mestre da Pontifícia Universidade Católica de São Paulo.
30
gestão de projetos de software tem se fortalecido ao longo dos anos em razão da necessidade de garantir a qualidade e o sucesso dos projetos de software. Aliada aos conceitos clássicos da área da administração, tais como planejar, coordenar e controlar, com os elementos específicos da engenharia de software em relação aos processos de software consegue integrar os aspectos tanto organizacionais quanto técnicos. As atividades organizacionais atribuídas à gestão de projetos de software vão desde o atendimento às necessidades do cliente em relação a um produto e/ ou serviço, até o relacionamento com os envolvidos em todo o ciclo de vida do projeto, já que as atividades técnicas englobam desde as metodologias de desenvolvimento de software até a implantação propriamente dita do software. Decidir sobre a utilização de um instrumento para aplicar as práticas administrativas principalmente em relação à gestão projetos de software torna-se adequado, pois, os ganhos que são obtidos com essa iniciativa
Fique por dentro: Este artigo descreve a dificuldade existente da aplicação da atividade de monitoramento e controle nos processos de desenvolvimento de software, apresentando como ferramentas e indicadores podem auxiliar a sua utilização constante em uma organização. Apesar dos processos de desenvolvimentos de software indicarem atividades ligadas ao monitoramento e controle, na gestão de projetos ainda há uma carência no uso efetivo dessas atividades.
acrescentam o aperfeiçoamento dos processos, mas existem fatores que devem ser observados. O trabalho da gestão de projetos de software é tentar cumprir o que foi planejado. Muitos projetos fracassam em seus objetivos ou não os alcançam plenamente devido a diversos desvios ou falhas que não foram identificados no seu planejamento. Para obter mais qualidade, não só no software, mas em todo o seu processo, deve-se realizar um planejamento minucioso. O planejamento diz como e onde a equipe deveria estar em determinado momento. O monitoramento e controle,
Engenharia de Software Magazine - Gerência de Projetos: Monitore e controle o desenvolvimento de software
PLANEJAMENTO
por sua vez, consistem em acompanhar as atividades plane jadas com a finalidade de identificar possíveis problemas ou desvios e deflagrar eventuais ajustes que possam ser necessários para fazer o projeto de volta ao seu caminho original. Monitorar e Controlar é definido pelo o PMI (Instituto de Gerenciamento de Projetos) como “coletar os dados do projeto referente ao plano de gerenciamento, produzindo medições de desempenho e divulgando essas in formações por meio de relatórios”. Dessa forma, podem ser tomadas ações corretivas quando desvios forem identificados, garantindo o atendimento dos objetivos do projeto. Analisando o monitoramento e o controle, pode-se dizer que enquanto no monitoramento estão às atividades envolvendo o acompanhamento e a coleta de dados a respeito do andamento, o controle consiste na tomada de ações frente aos desvios encontrados no monitoramento, e por isso é necessário que haja uma medição e a apuração de indicadores com as informações que serão reportadas à gestão de projetos de software. O problema em realizar o monitoramento e controle nos processos de desenvolvimento de software, pode estar relacionado com as seguintes situações:
• A tomada de decisão da gestão de projetos sem considerar
A forma de utilização do monitoramento e controle nos processos de desenvolvimento de software: nem sempre os
Com a análise desses dados, identificamos que 76% das empresas de certa forma adotam alguma forma de acompanhamento das fases e/ou atividades dos projetos porém, 24% das empresas não se preocupam em fazer nenhum monitoramento e controle. Esses dados não diferem do cenário quanto aos problemas mais frequentes enfrentados pelas empresas em relação aos seus projetos atribuídos a prazo (65,7%), escopo (61,7%) e custo (41,3%). Neste estudo, 18,4% dos problemas está relacionado à falta de uma ferramenta para o monitoramento e controle, indicando que 24,5% dos softwares mais utilizados são desenvolvidos internamente por opção da empresa, o que mostra que as empresas não conseguem encontrar uma ferramenta adequada devido às necessidades e particularidades internas. Cabe destacar que, habitualmente, o monitoramento e controle é considerado pelo nível operacional como uma ação de auditoria em que são tratadas as inconformidades das atividades e dos processos. Esse pensamento dif iculta a sua abordagem do que deve ser entendido, pois não é apenas uma tarefa externa que verifica como o processo está sendo conduzido, mas se ele é realmente entendido pela equipe e principalmente se gera valor aos envolvidos e responsáveis pelo processo. O monitoramento e controle nos projetos de software busca garantir a verificação do que deve ser realizado no projeto, ou seja, acompanhar os processos que são executados com as suas atividades, identificando ações corretivas e preventivas, estabelecendo assim maneiras de tomada de decisão na gestão de projetos de software. Se a execução do projeto tem como objetivo entregar produtos e/ou serviços planejados, o monitoramento e controle envolvem o acompanhamento destes resultados para garantir que estejam de acordo com o planejado e que o projeto continue seguindo o plano de gerenciamento do projeto.
•
processos e metodologias de desenvolvimento de software deixam explícito como deve ser feito o monitoramento e controle. E normalmente cada metodologia aborda o proces so de software buscando a execução das suas fases e atividades sem nenhum tipo de monitoramento e controle; • As ferramentas não são suficientes para o suporte das atividades de monitoramento e controle nos processos de desenvolvimento de software: algumas ferramentas dispo-
níveis no mercado que são utilizadas como apoio à gestão de projetos de software não oferecem opções suficientes para realizar o monitoramento e controle no acompanhamento das fases e/ou atividades no processo de desenvolvimento de software, pois devem apresentar alguns pontos e ter opções que permitam: - selecionar projetos de software com alinhamento às estratégias corporativas, analisando os seus impactos e riscos; - gerenciar os recursos envolvidos em vários projetos de software, compartilhando as suas informações de tempo, custo e qualidade; - gerenciar o retorno de investimento em pequenos, grandes e complexos projetos de software; - gerenciar o ciclo de vida dos projetos promovendo melhorias contínuas no processo de software; • Existem falhas no papel dos gerentes de projetos em relação ao monitoramento e controle nos processos de desenvolvimento de software: o monitoramento e controle fornecem
insumos importantes para que o processo de desenvolvimento de software possa ser melhorado nas suas fases e/ou atividades, mas a atuação gerencial precisa ser mais eficaz e ef iciente em relação às ações preventivas e/ou corretivas, pois de nada adianta ter instrumentos que auxiliam este processo se não existe uma atuação assertiva;
os indicadores e relatór ios de produtividade fornecidos pelo monitoramento e controle nos processos de desenvolvimento de software: os relatórios de desempenho extraídos dos indi-
cadores devem estar alinhados ao monitoramento e controle sendo uma maneira de trazer mais visibilidade aos gestores de projetos. Ainda que eles não sejam utilizados na sua totalidade, devem ser considerados em ações a serem tomadas não somente pelo conhecimento empírico, mas em informações consolidadas e confiáveis em relação aos problemas identificados nos processos de desenvolvimento de software.
Monitoramento e controle Uma pesquisa do PMI realizada em 2012 revelou a frequência com que as empresas brasileiras adotam atividades de monitoramento e controle em seus projetos. Nesta pesquisa identificou-se que: • 22% sempre adotam; • 54% adotam na maioria das vezes; • 24% nunca adotaram.
Edição 69 - Engenharia de Software Magazine
31
O monitoramento e controle fornecem subsídios para as atividades nos processos de software. Com essas informações disponíveis aos gerentes de projetos, tem-se a possibilidade de atuação constante ao que deve ser desenvolvido e entregue por sua equipe, proporcionando melhorias em relação à condução do projeto de forma assertiva. A finalidade do monitoramento e controle é determinar se o projeto está prosseguindo conforme planejado. Essa fase consiste em três etapas: 1. Monitoramento das atividades contínuas do projeto (onde estamos); 2. Comparação das variáveis do projeto (custo, esforço, tempo, recursos, etc.) com o plano real (onde deveríamos estar); 3. Identificação de ações corretivas (como voltamos ao caminho certo).
Monitoramento e controle no RUP (Rational Unified Process) Na disciplina de gerenciamento de projetos do RUP, encontramos uma tarefa “definir monitoramento e processos de controle”, que tem o objetivo de definir as informações e os
processos que serão utilizados para monitorar e controlar o progresso, a qualidade e os riscos do projeto. Uma outra tarefa referente ao gerenciamento de projetos é “monitorar status do projeto” que captura o trabalho diário e contínuo, incluindo monitoramento de status do projeto, relatório para envolvidos lidando com as situações atuais e os problemas detectados. No RUP, o monitorar e controlar o projeto permeiam todas as tarefas essenciais até a finalização do projeto conforme pode ser observado na Figura 1. Com a utilização do RUP nas suas etapas e atividades, podemos aplicar o monitoramento e controle para que o projeto tenha os resultados esperados e definidos desde a sua concepção até a transição, buscando abordar todas as suas disciplinas e aplicando indicadores que possam ajudar a gestão de projetos de software por meio de ações corretivas e preventivas.
Monitoramento e controle no PMBOK O monitoramento e controle de projetos segundo o PMBOK têm o benefício de observar e mensurar o desempenho do pro jeto de forma periódica e uniforme para identificar variações
Figura 1. Monitoramento e Controle no RUP
32
Engenharia de Software Magazine - Gerência de Projetos: Monitore e controle o desenvolvimento de software
PLANEJAMENTO
em relação ao plano de gerenciamento do projeto definido que inclui: • Controlar as mudanças e recomendar ações preventivas em
antecipação a possíveis problemas; • Monitorar as atividades do projeto em relação ao plano de
dos riscos residuais, identificação de novos riscos e avaliação do processo de risco durante todo o projeto. • Administrar as r equisições: gerenciamento das aquisições e monitoramento dos desempenhos dos contratos, fazendo mudanças e correções conforme necessário.
gerenciamento e a linha de base de desempenho do mesmo; • Influencia r os fatores que poderiam impedir o controle inte-
grado de mudanças, para que somente as mudanças aprovadas sejam implementadas. Este monitoramento contínuo oferece à equipe do projeto uma visão melhor sobre a saúde do mesmo e identifica quaisquer áreas que requeiram atenção adicional. Não apenas monitora e controla o trabalho que está sendo feito durante um grupo de processos, mas também monitora e controla o projeto inteiro, incluindo os seguintes processos (apresentados na Figura 2): • Monitorar e controlar o trabalho no projeto: acompanhamento,
avaliação e regulação do progresso para atender aos objetivos de desempenho definidos no plano de gerenciamento do projeto; • Realizar o controle integrado de mudanças: avaliação de
todas as solicitações de mudanças, aprovação de mudanças e gerenciamento das mesmas em entregas, ativos de processos organizacionais, documentos e plano de gerenciamento do projeto; • Verificar o escopo: formalização da aceitação das entregas
terminadas no projeto; • Controlar o escopo: monitoramento do andamento do escopo
A utilização do PMBOK no monitoramento e controle nos processos de software explicita uma documentação em todas as áreas, tornando esta atividade aderente ao que deseja a gestão de projetos de software.
Ferramentas para monitoramento e controle Os softwares para o gerenciamento de projetos são usados com diversos fins como: planejar, monitorar, controlar, relatar e comunicar a situação dos projetos. Um software de monitoramento e controle implica em determinar quais dados coletar, como, quando e quem irá coletá-los, analisa-los e relatar o progresso alcançado: • Quais dados são coletados: dados coletados são determinados por qual sistema de medição será usado para o controle do projeto. • Coletar dados e fazer análise: com a definição de quais dados são coletados, o próximo passo é estabelecer por quem, quando e como os dados serão agregados; • Relatórios e o modo de reportar: quem recebe os relatórios de desempenho? As partes interessadas e gerentes necessitam de diferentes tipos de informação relacionadas ao projeto.
do projeto e do produto e gerenciamento das mudanças feitas na linha de base do escopo; • Controlar o cronograma: monito ramento do andamento do projeto para atualização do seu progresso e gerenciamento de mudanças feitas na linha de base do cronograma; • Controlar os custos: monitoramento do andamento do projeto para a atualização do seu orçamento e gerenciamento de mudanças feitas na linha de base dos custos; • Realizar o controle da qualidade:
monitoramento e registro dos resultados da execução das atividades de qualidade para avaliar o desempenho e recomendar as mudanças necessárias; • Reportar o desempenho: coleta e distribuição de informações sobre o desempenho, inclusive relatórios de andamento, medições do progresso e previsões; • Monitorar e controlar os riscos:
implementação de planos de respostas aos riscos, acompanhamento dos riscos identificados, monitoramento
Figura 2. Monitoramento e Controle no PMBOK
Edição 69 - Engenharia de Software Magazine
33
A importância dos softwares no monitoramento e controle de projetos é de fornecer insumos essenciais para o processo de desenvolvimento de software dos projetos desenvolvidos e, portanto, as informações que são coletadas, analisadas e disponibilizadas ajudam na tomada de decisão quanto ao que precisa ser apurado durante as etapas e atividades previstas e concluídas em um projeto.
Indicadores para o monitoramento e controle Podemos perceber certa resistência em se medir os processos de desenvolvimento de software através de indicadores de desempenho. Um dos motivos dessa resistência é a dificuldade de se identificar indicadores que realmente ajudem na produção de informações importantes. Apesar de termos a possibilidade de utilizar estes indicadores de forma favorável em ações para melhorar os processos de desenvolvimento de software, a gestão de projetos continua no “achismo” e no seu “feeling”, mas isso não é o ideal, pois existem métricas e informações que não estão sendo consideradas. No desenvolvimento de software podemos aplicar t rês tipos de indicadores que são os mais utilizados para medir o desempenho dos processos organizacionais: • Indicador de qualidade: relação entre o que é produzido
(certo ou errado) pelo total produzido; • Indicador de produtividade: relação entre o total produzido
sobre os recursos consumidos; • Indicador de capacidade: mede a produção em um espaço
de tempo (capacidade da produção). A utilização desses indicadores no monitoramento e controle, considerando a sua documentação como os artefatos requer idos, deve atentar para: • Indicador de qualidade: total de artefatos que voltaram para
o retrabalho dividido pelo total de artefatos entregues; • Indicador de produtividade: total de artefatos entregues
dividido pelo total de funcionários trabalhando no projeto; • Indicador de capacidade: total de artefatos entregues divi -
dido pelo tempo total do projeto. Em projetos, devemos contextualizar a utilização dos indicadores como se fossem fotografias instantâneas, mas que indicam tendências. Aconselha-se utilizar aqueles que considerarem os mais adequados ao contexto que foram criados na própria empresa, ou os mais usuais do mercado. Ter estes indicadores atribuídos à gestão de projetos nos ajuda a:
Benefícios do monitoramento e controle A aplicação do monitoramento e controle no processo de desenvolvimento de software contribui e serve como um mecanismo de aproximação entre as áreas gerenciais e técnicas, gerando dados e indicadores que tornam mais previsíveis e assertivos os planejamentos para a tomada de decisão na gestão de projetos de software. Podemos levar em consideração os processos de desenvolvimento de software para o monitoramento e controle no aspecto da gestão de projetos, as seguintes contribuições: • A atividade de monitoramento e controle quando realizada
nos processos de software deve estabelecer processos, atividades e tarefas que possam direcionar a sua utilização; • As ferramentas que o monitoramento e controle utilizam para
o processo de software podem direcionar ações corretivas e preventivas, que devem ser informadas à gestão de projetos para que as devidas providências necessárias ao trabalho realizado pelo gerente de projetos e sua equ ipe sejam tomadas; • A atuação gerencial tendo como uma das suas premissas a
execução da atividade de monitoramento e controle nos processos de software como ferramenta diária de trabalho para acompanhar os projetos e sistemas de uma organização; Por fim, vale destacar que os indicadores de produtividade atrelados ao monitoramento e controle nos processos de desenvolvimento de software são subsídios fornecidos que podem ter dados, informações atualizadas e consistentes para a tomada de decisão na gestão de projetos. Portanto, é necessário que possam ser diversificados de acordo com a realidade da organização. Links: GRAY, Clifford F., Erik W. Larson: Gerenciamento de Projetos: O Processo Gerencial; Tradução Dulce Cattunda, Frederico Fernandes – 4 ed. Porto Alegre: AMGH, 2010. KERZNER, H. Project Management - A System Approach to Planning,Scheduling, and Controlling, 7º ed., New York, John Wiley & Sons Inc.,2001. MENDONÇA, Mauro. TAM – Técnicas para Análise e Melhoria de Processos. Curso em Fita de Vídeo, LinkQuality, 2002. PMI-Project Management Institute. Pesquisa PMSURVEY.ORG 2012: PMI. 2012. http://www.pmsurvey.org/ PMBOK. A Guide to the Proiject Management Body of Knowledge, PMI-Projec t Management Institute, Newtown Square, Pennsylvania, USA, 2008.
• Ter uma visão melhor do processo de desenvolvimento de
software;
Você gostou deste artigo?
• Identificar os riscos; • Identificar e resolver os problemas antes que se tornem
Dê seu voto em www.devmedia.com.br/esmag/feedback
críticos; • Melhorar a comunicação da equipe com a organização • Avaliar o desempenho do projeto.
34
Ajude-nos a manter a qualidade da revista!
Engenharia de Software Magazine - Gerência de Projetos: Monitore e controle o desenvolvimento de software
Engenharia Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros
Gestão de Projetos: Usando processos de desenvolvimento Fique por dentro:
Rommel Gabriel Gonçalves Ramos
[email protected]
Possui Graduação em Administração de Sistemas de Informação pelo Centro Universitário Una (2004).Pós-graduação (especialização) em Melhoria de Processo de Software pela Universidade Federal de Lavras (2007). Mestrado em Tecnologias da Inteligência e Design Digital (TIDD) na PUC/SP.(2013).Atualmente e consultor de TI na Caixa Econômica Federal. Professor do SENAC/SP do Curso de Pós-Graduação (Especialização) em Gestão e Governança de Tecnologia da Informação).Professor Assistente da FMU - Faculdades Metropolitanas Unidas do Curso de Análise e Desenvolvimento de Sistemas.
Daniel Couto Gatti
[email protected]
Possui graduação em Ciência da Computação pela Pontifícia Universidade Católica de São Paulo (1995), Mestrado em Comunicação e Semiótica pela Pontifícia Universidade Católica de São Paulo (2002) e Doutorado em Educação Matemática pela Pontifícia Universidade Católica de São Paulo (2009). Atualmente é Diretor da Faculdade de Ciências Exatas e Tecnologia da PUC/SP, professor da Faculdade de Tecnologia Bandeirantes, professor titular do Instituto Brasileiro de Tecnologia Avançada e assistente mestre da Pontifícia Universidade Católica de São Paulo.
Este artigo descreve como a gestão de projetos utiliza a engenharia de software para a modelagem de produtos de software e, consequentemente, as atribuições requeridas no gerenciamento de projetos. O objetivo principal é apresentar a aplicação quanto às técnicas, modelos, metodologias e ferramentas para a construção do produto de software em um determinado cenário. O modelo de desenvolvimento utilizado na empresa é baseado em controles institucionais. Os cenários apresentados neste artigo são os mais usados atualmente em uma empresa de grande porte,
A
s empresas de desenvolvimento de software buscam alguma forma de gerenciar os seus projetos de software, desejando ter um modelo e/ou processo de “sucesso” que possa atender todas as etapas, fases e atividades na produção do software. Entretanto, não existe uma receita que garanta à empresa alcançar este objetivo. O SEI - Software Engineering Institute constatou que o principal problema que aflige as organizações de software é gerencial e preconizou que as organizações
que não possui como atividade final o desenvolvimento de software, mas que necessita ter a visibilidade para as suas áreas gestoras de projetos e negócios, verificando e acompanhando as fases, etapas e atividades previstas nos processos de desenvolvimento, comumente utilizados em várias empresas de desenvolvimento de software, tendo como premissa a construção e a manutenção de produtos e serviços que são documentados e aderentes aos normativos internos desta empresa, estipulados pelas áreas gestoras de tecnologia da informação.
precisam vencer o seu buraco negro que é o seu estilo de gerenciar de maneira informal, sem métodos e sem técnicas. Constantemente são oferecidas em diversos eventos de tecnologia da informação voltados para o gerenciamento de projetos: ferramentas, metodologias, modelos e melhores práticas que possam tornar o desenvolvimento de software mais eficaz e eficiente, tendo em vista que hoje somos muito dependentes da mão-de-obra técnica especializada para o processo de produção de software.
Edição 69 - Engenharia de Software Magazine
35
A gestão de projetos de software enfatiza e deixa evidente que o gerenciamento de projetos deve ser melhorado, e por isso, modelos e normas evoluíram principalmente com a inclusão de práticas gerenciais para os projetos de software como, por exemplo: o CMM para CMMI e a ISO 12207 para a ISO 15504. O problema da indústria de software é mais gerencial do que técnico, todavia, o gerenciamento do projeto não está sendo considerado como deveria. 75% de todos os sistemas de software falham e a causa principal é o pobre gerenciamento por parte do desenvolvedor e adquirente, deixando claro que o problema não é de desempenho técnico. Portanto, um fator preponderante ao processo de desenvolvimento de software é a gestão, pois precisamos de mais gerentes de projetos que possuam além da experiência técnica, uma fundamentação teórica e prática maior na parte de gerenciamento. Ou seja, para alcançar alguns resultados em um determinado projeto são necessárias algumas habilidades essenciais e decisivas. Uma empresa que desenvolve software precisa ter além de bons profissionais, ferramentas, modelos, técnicas e processos. Toda empresa que desenvolve um software precisa de processos que possam ser seguidos, acompanhados, monitorados e controlados, como já preconiza algumas técnicas do gerenciamento de projetos e a própria gestão de processos. Os processos devem ser utilizados por nossas equipes de projetos, sendo essencial para alcançar aquilo que se espera de todo o produto de software que é atender as necessidades dos usuários.
Engenharia de software na gestão de projetos A engenharia de software tem por finalidade auxiliar na construção de software da melhor maneira possível. Desde os anos 1960, quando a frase “a crise de software” foi pronunciada, muitos problemas desta área foram identificados, e muitos deles ainda persistem, tais como: • Previsão pobre - desenvolvedores não prevêem adequada mente quanto tempo e esforço serão necessários para produzir um sistema de software que satisfaça às necessidades (requisitos) dos clientes/usuários. Sistemas de software são geralmente entregues muito tempo depois do que foram planejados; • Programas de baixa qualidade - programas de softwar e não
executam o que o cliente deseja como consequência, talvez, da pressa para se entregar o produto. Os requisitos originais podem não ter sido completamente especificados ou podem apresentar contradições e isto pode ser descoberto muito tarde durante o processo de desenvolvimento; • Alto custo para manutenção - a manutenção pode ser cor retiva, quando ocorrem enganos (erros, falhas) no sistema já entregue, ou evolutiva quando novas características são adicionadas ao sistema de software. Ambas são caras quando o sistema original foi construído sem uma arquitetura clara e visível; • Duplicação de esforços - é difícil compartilhar soluções ou
reusar códigos em função das características de algumas linguagens adotadas, por falta de confiança no código feito por
36
outra pessoa e até mesmo pela ausência/deficiência de documentação das rotinas e dos procedimentos já construídos. Para solucionar alguns destes problemas, muitas empresas de software têm adotado processos de desenvolvimento de software. Todavia, os paradigmas metodológicos para desenvolvimento de software têm sido considerados somente em termos de “um método” de análise/projeto/implementação, isto é, um conjunto de conceitos, técnicas e notações. Contudo, a grande maioria das organizações que desenvolvem software sente muita dificuldade em entender, definir e gerenciar estes processos. As empresas de software devem buscar os seus próprios ambientes para existirem e operarem. Abordagens da indústria manufatureira, por exemplo, não têm demonstrado serem adequadas à indústria de software. A utilização mais sistemática de processos foi iniciada nos anos 30. Nesta época, iniciou-se u m trabalho em melhoria de processo com os princípios do controle estatístico. Nos anos 70, notou-se que as organizações de manufatura poderiam ser estudadas de acordo com a qualidade de sua produção e definiu-se cinco estágios sequenciais e cumulativos do processo de produção, baseados principalmente nas atitudes gerenciais encontradas em cada estágio. Estes estágios indicam a qualidade do processo de produção. Nos anos 80, começou-se a aplicar estes princ ípios de controles estatísticos e os estágios de qualidade para software. Os princípios e conceitos básicos que fundamentaram os modelos de maturidade da capacidade foram descritos nesta época. Pesquisas e estudos que foram realizados nos anos 90 demonstraram que o gerenciamento de projeto é a causa mais evidente das falhas na execução e entrega de produtos e serviços de software. Isso demonstra que a engenharia de software torna-se essencial, pois busca a utilização dos modelos que permitem especificar, projetar, implementar e manter os softwares, aplicando as práticas de gerência de projeto e demais disciplinas, com o objetivo de trazer para as empresas produtividade e qualidade.
Gerenciamento de projetos A gerência de projetos é a primeira camada do processo de engenharia de software. O termo “camada” em vez de etapa, fase ou atividade, é porque ela abrange todo o processo de desenvolvimento do início ao fim. Uma das tentativas iniciais de resolver falhas em projetos foi incentivada e financiada pelo DOD (Departamento de Defesa Americano). O Software Engineering Institute (SEI) da Universidade Carnegie Mellon desenvolveu um modelo de maturidade de desenvolvimento de software, o CMM (Capability Maturity Model). O CMM (Capability Model Maturity) indica que uma organização pode ser aferida ou avaliada comparando-se suas práticas reais com aquelas que o modelo de maturidade de capacitação prescreve ou recomenda. Essa aferição produz u m diagnóstico da organização quanto aos seus processos.
Engenharia de Software Magazine - Gestão de Projetos: Usando processos de desenvolvimento
ENGENHARIA
O diagnóstico serve de base para recomendações de melhoria de processos, e estas recomendações podem ser consolidadas em um plano de melhoria. Além dos benefícios naturais, como produtividade e qualidade, acredita-se que em curto prazo as certificações dos processos fabris será um pré-requisito básico para contratações de produtos de software. Por esses motivos, o CMM (Modelo de Capacidade e Maturidade) tornou-se ao longo de uma década o mais conhecido, usado e respeitado pela comunidade de engenharia de software, com o objetivo principal de estabelecer um padrão de qualidade para software desenvolvido para as forças armadas. Atualmente, o modelo de referência é o Capability Maturity Model Integration - CMMI v1.3, lançado em 2002 como evolução do CMM. As empresas de software que alcançam níveis de maturidade mais elevados possuem processos capazes de produzir produtos extremamente confiáveis dentro de limite de custo e cronograma previsível. À medida que cresce o entendimento dos níveis de maturidade mais elevados, as áreas de processos existentes vão sendo redefinidas e outras ainda podem ser adicionadas ao modelo. Além dos modelos CMM/CMMI, outra publicação que influencia a abordagem de desenvolvimento de software é o Corpo de Conhecimentos em Gerência de Projetos - PMBOK. O PMBOK descreve os conhecimentos necessários para uma gerência de projetos não apenas de software, mas de outras áreas de conhecimento, definindo como aplicar os conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. Dentre algumas das atividades de um gerente de projeto estão: • Identificar as necessidades do projeto; • Estabelecer objetivos claros e alcançáveis; • Equilibrar as demandas conflitantes de qualidade, escopo,
tempo e custo; • Adaptar as especificações, planos e a abordagem às diferentes
preocupações e expectativas das diversas partes interessadas; e; • Minimizar os impactos negativos das incertezas dos
projetos. Além da questão de conhecimentos em gerência de projetos, a utilização de alguma ferramenta apropriada facilita o acompanhamento e o controle do projeto no sentido de atender as demandas de desenvolvimento de software da área de negócio de um determinado sistema dentro da organização, classificando assim as suas prioridades no seu atendimento. Um processo de gerenciamento de projeto deve: identificar, estabelecer, coordenar e monitorar as atividades, as tarefas e os recursos necessários para um projeto produzir um produto e/ou serviço, de acordo com seus requisitos. Todavia, gerenciar projetos de software é uma atividade complexa devido a uma série de fatores, tais como: • Dinamicidade do processo; • Grande número de variáveis envolvidas; • Exigência de adaptabilidade ao ambiente de desenvol-
vimento; • Constantes alterações no que foi planejado.
Estes fatores dificultam o trabalho das equipes de desenvolvimento na medição do desempenho dos projetos, na verificação de pontos falhos, no registro de problemas, na realização de estimativas e planejamentos adequados. De acordo com o PMBOK, “as atividades da organização executora é que determinam as responsabilidades, os objetivos e as políticas, de modo que o projeto atenda às necessidades que motivaram sua realização, com as atividades dos processos conduzidos do início ao fim, conforme adequado”.
Aplicação da gestão de projetos nas empresas de software As organizações devem buscar alternativas sobre como fazer a gestão de seus projetos de software, visando a diminuição dos fracassos e a melhoria na qualidade de seus produtos e serviços. Os processos tradicionais de desenvolvimento e a gerência de projetos têm sido caracterizados como uma descrição linear de um processo sequencial. Qualquer projeto de software será beneficiado pelo uso de algum tipo de modelo, inclusive no setor comercial, em que às vezes é mais comum distribuir softwares inadequados devido à produtividade oferecida pelas linguagens de programação visual. A modelagem poderá auxiliar a equipe de desenvolvimento a visualizar melhor o planejamento do sistema e permitir que o desenvolvedor seja mais rápido ajudando a construir o item correto. No desenvolvimento de um software, podemos utilizar modelos existentes no mercado como referência de forma que seja uma metodologia de sucesso. Neste contexto, é essencial o uso da gestão de projetos para descrever como um software deva ser construído e modelado utilizando ferramentas, padrões e normas baseados em processos e como eles serão aplicados em quem desenvolve e/ou adquire soluções para conduzir o seu negócio no dia a dia. Isto deve ser uma meta a se alcançar nas empresas que estão em busca de benefícios e resultados, principalmente para esta belecer melhorias contínuas na mudança de paradigmas, e na maneira de introduzir inovações tecnológicas para a resolução de problemas rotineiros e complexos. Contudo, as organizações precisam adaptar suas estruturas, estratégias e políticas para satisfazerem os novos ambientes e a crescente demanda da sociedade contemporânea por sistemas de informação que são construídos a partir da iniciativa da gestão de projetos. A falha nos projetos é discutida em algumas pesquisas. Em uma delas, realizada nos anos de 1992 e 1993, mais de 60% dos projetos pesquisados nos Estados Unidos estavam atrasados e mais da metade ultrapassava em 50% o prazo planejado. Um outro estudo conduzido em 1999 indicou que somente 37% dos sistemas de informação foram finalizados no prazo estipulado. Adicionalmente, dos 63% dos projetos que atrasaram 42% seriam finalizados acima do orçamento. O Standish Group, através de um estudo chamado de relatório do “Chaos”, identificou que as empresas dos Estados Unidos gastaram US$81 milhões em projetos de software, sendo que 31% dos projetos Edição 69 - Engenharia de Software Magazine
37
de software estudados foram cancelados antes de estarem concluídos, 53% excederam mais do que 50% a sua estimativa de custo e somente 9% dos projetos, em grandes empresas, foram entregues no tempo e orçamento previstos; para empresas de pequeno e médio porte, os números melhoraram de 50% para 28% e de 9% para 16%. Tem-se tentado resolver essas falhas através de modelos de melhoria e processo que estão baseados no Triângulo Mágico da Força do Desenvolvimento de Software (Magic Triangle of Software Development Greatness). Qualquer deficiência em alguma área do triângulo se manifestará em riscos de falha dos projetos (ver Figura 1). Então, é evidente que temos que trabalhar em todos os seus aspectos, sendo que uma força influencia na outra. Por exemplo, processos imaturos fazem com que tenhamos uma deficiência no estabelecimento do perfil técnico requerido para exercer uma atividade e não se consiga obter o melhor da tecnologia oferecida.
na verdade já se beneficiam dos avanços das tecnologias de informação e comunicação (TICs), que também poderão sofrer as consequências de um erro, defeito ou falha de um software. As empresas que utilizam modelos apropriados para a construção e manutenção de um software demonstram ter um nível de maturidade, adicionando mais produtividade com competência técnica, operacional e gerencial, o que requer delas o controle sobre seus processos imaturos, maduros e institucionalizados. Já em 1989, foi constatado que a ausência de práticas administrativas no desenvolvimento de software é a principal causa de sérios problemas enfrentados pelas organizações, tais como: atrasos em cronogramas, custo maior do que o esperado e presença de defeitos, ocasionando uma série de inconveniências para os usuários e enorme perda de tempo e de recursos. A meta da gestão de projetos é conseguir exceder as neces sidades e expectativas dos stakeholders. Todavia, satisfazer ou exceder estas necessidades envolve um balanceamento entre as várias demandas concorrentes em relação aos itens abaixo: • escopo, tempo, custo e qualidade (objetivos do projeto); • stakeholders com necessidades e expectativas diferenciadas; e • requisitos identif icados (necessidades) e requisitos não iden-
tificados (expectativas). A gestão de projetos sendo conduzida pela gestão de processos pode trazer diversos benefícios à organização, tais como: • Descrição precisa e não ambígua dos processos de negócio
existentes; • Melhoria na definição de novos processos; • Maior eficácia na coordenação do trabalho entre diferentes Figura 1. Triângulo Mágico da Força de Desenvolvimento de Software
agentes; • Obtenção, em tempo real, de informações precisas sobre o
O processo de software, portanto, é essencial para que tenhamos qualidade no produto de software e consigamos atender a qualidade, orçamento, prazos e recursos definidos no projeto. Organizações que sejam capazes de integrar, harmonizar e acelerar seus processos de desenvolvimento e manutenção de software tendem a ser mais bem sucedidas no mercado. Geralmente um projeto de software requer a participação de uma ou mais equipes, cooperando para a construção de determinado produto de software. É necessário que exista consenso sobre o processo a ser seguido desde a concepção até a implantação do produto de software, para que interpretações pessoais não desviem o foco do trabalho ou introduzam erros durante o desenvolvimento. Todos estes fatores levam as organizações desenvolvedoras de softwares a atuar fortemente na qualidade de seus produtos, que é um dos principais objetivos da engenharia de soft ware. Contudo, a qualidade dos produtos de software, que também ficou evidente para a evolução da qualidade dos produtos das indústrias, está fortemente relacionada à qualidade do processo de software. A utilização de software já faz parte do cotidiano de praticamente todas as pessoas. Mesmo aquelas que pensam que nunca utilizaram um software, internet, ou um computador,
38
andamento dos processos e; • Padronização dos processos executados, de forma manual
ou automatizados, pela organização. Desde o começo da década de 1990, a corrida pela excelência na gestão de projetos tem assumido uma importância cada vez maior. Os benefícios da gestão de projetos são óbvios hoje tanto para os clientes quanto para os fornecedores. De fato, a excelência em gestão de projetos se tornou uma arma compet itiva que atrai novos negócios e mantém os clientes tradicionais. Para atender a demanda de maneira eficaz em um a mbiente caracterizado pela velocidade das mudanças, torna-se indispensável um modelo de gerenciamento baseado no foco em prioridades e objetivos. Por essa razão, o gerenciamento de projetos tem crescido de maneira tão acentuada no mundo nos últimos anos. Outro fator que impulsionou o gerenciamento de projetos é o crescimento da competitividade. Quem for mais rápido e competente certamente conseguirá melhores resultados. Ainda hoje, esta afirmação tem sido confirmada por diversos autores. Na atual cultura das organizações de soft ware, o planejamento, quando ocorre, é feito de forma superficial. Muitos projetos de software são realizados sem um planejamento de
Engenharia de Software Magazine - Gestão de Projetos: Usando processos de desenvolvimento
ENGENHARIA
como a ideia modelada pelo levantamento de requisitos e necessidades dos clientes pode ser transformada em produto. Os gerentes de projeto de software estão desacostumados a estimar. Quando estimam, costumam basear-se em estimativas passadas, mesmo sabendo que elas podem estar incorretas (não sabem também precisar o quanto elas estão incorretas). Há gerentes que se recusam a estimar somente por julgarem perda de tempo, uma vez que correm o risco de obter resultados incorretos e, portanto, estarem desperdiçando tempo. Boas estimativas de custo, esforço e prazo de software requerem um processo ordenado que defina a utilização de métricas de software, método e ferramenta de estimativa. As empresas de software, de forma geral, não detêm conhecimentos e recursos para isso. Estimar, medir e controlar um projeto de software são ta refas difíceis, pois o desenvolvimento de software é uma atividade criativa e intelectual, com muitas variáveis envolvidas (como metodologias, modelos, técnicas, ferramentas, tecnologias, recursos e atividades diversas). Os gerentes inexperientes tentam cumprir prazos dando a máxima velocidade na fase inicial e estão despreparados para os momentos de impasse, quando os ajustes são inevitáveis. A dinamicidade do processo de software dificulta também o gerenciamento efetivo de projetos de software, devido às alterações constantes nos planos de projetos, redistribuição de atividades, inclusão/exclusão de atividades, adaptação de cronogramas, realocação de recursos, novos acordos com os clientes, entregas intermediárias não previstas etc. Um projeto de software também deve se adaptar ao ambiente, dependendo da disponibilidade de recursos, ferramentas e habilidades do pessoal ou equipe. Outros fatores ainda agravam os problemas da gestão de pro jetos de software em empresas, tais como: inexistência de um processo definido, recursos pessoais e financeiros limitados, falta e/ou pouca cultura em processos, pouco treinamento em engenharia de software, imaturidade metodológica, crescimento ocorrido por demanda, falta de experiência administrativa por parte dos gerentes e diretores e falta de definição das metas organizacionais. Tem-se também a persistência de um conhecido problema no desenvolvimento de software: muitos projetos consomem mais recursos do que o planejado e demoram mais tempo para serem realizados, possuem menos funções e menor qualidade do que o esperado. Relatos de insucesso na produção de sistemas de software podem ser encontrados em diversos estudos de casos e experimentos documentados ao longo dos últimos anos.
O modelo de desenvolvimento para a gestão de projetos Partindo do pressuposto de que uma organização de grande porte utiliza um processo padrão de desenvolvimento de software, e que nele são apresentados os controles institucionalizados com seus cenários, é possível ter a visão compart ilhada sobre como a gestão de projetos percebe os marcos que são desenvolvidos para um novo produto de software, aferindo
também a sua manutenção com uma modelagem adequada. O processo padrão estabelece o conjunto de elementos fundamentais que guia o desenvolvimento e a manutenção de sistemas. Ele define uma estrutura única a ser seguida por toda a equipe envolvida em projetos de software, independentemente das características do software a ser desenvolvido e das técnicas a serem utilizadas. Essas técnicas são definidas de acordo com as necessidades do projeto, ambiente, a preferência e competência da equipe multidisciplinar envolvida. A inovação tecnológica é um diferencial que deve ser incentivado. É o ponto de partida para a instanciação dos processos de software adequados às diferentes características de cada projeto, permitindo economia de tempo e esforço na definição do processo a ser seguido. As orientações sobre as técnicas mais utilizadas são apresentadas como cenários e também compõem a metodologia de sistemas que deu suporte à construção de grande parte dos sistemas. Os modelos instanciam os processos de desenvolvimento que são associados a estas técnicas e são disponibilizados dentro dos cenários através de casos de desenvolvimento. Observe a Figura 2. Este modelo exemplifica a estrut ura do modelo de desenvolvimento dos sistemas. O processo padrão está normatizado e estabelece controles rigorosos com o foco na preservação institucional. Adicionalmente, a título de orientação, são apresentados cenários direcionados a técnicas específicas, de acordo com a experiência anteriormente adquirida (o conhecimento acumulado no desenvolvimento de sistemas, cujo registro foi apropriado através do grupo de trabalho). O uso de abordagens como o RUP, conforme Figura 3 , contemplará atividades e artefatos efetivamente indispensáveis à instituição, incluindo os controles institucionais, e que deverá ser flexível o suficiente para atender às diversas situações comuns ao desenvolvimento, em qualquer tipo de projeto. Se você depende de sua capacidade para desenvolver e implantar software, que é essencial para o sucesso da i nstituição, ele irá ajudá-lo, pois foi desenvolvido visando dois grupos primários de usuários: • Profissionais de desenvolvimento de software que trabalham
como parte de uma equipe de projeto, incluindo os investidores desses projetos de desenvolvimento de software; • Profissionais de engenharia de processo, especificamente
engenheiros de processo de software e gerentes. Os profissionais de desenvolvimento de software podem encontrar orientação sobre o que é exigido deles nas funções definidas. Um profissional que trabalha em um projeto de engenharia de software é designado a uma ou mais funções definidas, e em que cada função particiona um conjunto de tarefas e produtos de trabalho pelos quais essa função é responsável. Também é fornecida orientação sobre como essas funções trabalham em conjunto, em termos das atividades requeridas para representar o processo configurado, referenciado como o processo de entrega. Além disso, são fornecidas várias Edição 69 - Engenharia de Software Magazine
39
visualizações com o produto que são focalizadas em diferentes grupos de profissionais de engenharia de software. Para um profissional de desenvolvimento de software, este ambiente fornece uma definição de processo comum e central, que todos os membros da equipe de desenvolvimento de software podem compartilhar, ajudando a assegurar uma comunicação clara e sem ambiguidade entre os membros da equipe.
Isso ajuda você a desempenhar a sua parte esperada na equipe de pro jeto, tornando claro quais são as suas responsabilidades. A técnica de análise estruturada baseiase na decomposição funcional estruturada de sistemas através de Diagramas de Fluxo de Dados (DFDs) que descrevem o sistema como um conjunto de processos funcionais que realizam transformações de informação e comunicam-se através
de fluxos de informação. Através do Diagrama de Entidade e Relacionamento (DER) são enfatizados os dados e os relacionamentos entre eles. Na análise estruturada os processos mais complexos são decompostos em subprocessos constituintes e seus fluxos de informação, formando-se uma estrutura hierárquica de processos. Esta metodologia fornece um conjunto coerente e integrado de métodos e regras, que no seu conjunto formam uma técnica estruturada de análise e projeto de sistemas baseada nos seguintes conceitos: abordagem top-down, modelagem funcional, representação gráfica do modelo, dicionário de dados e a descrição de processos e procedimentos, além de trabalho em equipe e documentação. Assim, o processo de desenvolvimento de sistemas na análise e projeto estruturados baseia-se em (ver Figura 4): • Definir os fluxos de dados recebidos
pelo sistema, entradas; • Definir os fluxos de dados fornecidos
pelo sistema, saídas; e • Definir os dados que devem ser arma-
zenados e os processos que devem ser executados para transformar os fluxos de entrada nos fluxos de saída. Figura 2. Modelo de Desenvolvimento de Sistemas de Software
Figura 3. Rational Unified Process
40
Engenharia de Software Magazine - Gestão de Projetos: Usando processos de desenvolvimento
A exibição de dados, composto de diagramas de entidade relacionamento, é um registro do que está no sistema, ou o que está fora do sistema que está sendo monitorado. É a visão estática estrutural. Sob o ponto de vista dinâmico, o diagrama de transição de estado define quando as coisas acontecem e as condições em que eles acontecem. A análise estruturada, de maneira geral, compreende os processos: Levantamento, Análise, Projeto, Codificação, Teste, Implantação e Manutenção. Usualmente adota-se uma abordagem em cascata. Esta abordagem é caracterizada pela existência de um início e fim de cada fase do processo de desenvolvimento, sendo a formalização do término de uma fase requerida antes que se inicie a próxima. Pode ser utilizada quando for possível adotar seus métodos, técnicas e ferramentas, pelas equipes de desenvolvimento, garantindo-se o rigor dos seus
ENGENHARIA
resultados. Além disso, é recomendada quando for pos sível a comunicação entre clientes e usuários e a equipe de desenvolvimento de forma a se garantir a clareza de ideias e o rigor da especificação. Isso pressupõe uma equipe de desenvolvimento capaz, com expertise técnica e habilidade de comunicação. Deve ser aplicada preferencialmente na construção/manutenção de sistemas de médio e grande porte, cujos requisitos se jam relativamente estáveis. A metodologia poderá ser utilizada no início de um novo projeto de desenvolvimento de software e também em manutenções e em ciclos de desenvolvimento subsequentes após a implantação do sistema em produção.
Figura 4. Analise estruturada
Os controles institucionais definidos pela empresa que tem como premissa a utilização de modelos de software são eventos fundamentais para o processo de desenvolvimento, e exigem algum tipo de aprovação de produto ou servem de insumo para uma etapa seguinte e se não realizados, impedem a continuidade do processo (ver Figura 5). Esses controles podem significar ainda a geração de produto explicitamente recomendado, normalmente ligados à política de segurança da informação ou à gestão de conhecimento. Os controles institucionais sempre necessitam de uma evidência de sua realização. Além dos controles instituições, no modelo de desenvolvimento existem guias de utilização padronizados por um comitê de melhoria de processo voltadas para os gestores, gerentes, desenvolvedores, usuários e demais envolvidos no processo, trazendo diversas orientações da estrutura que podem ser usadas em detrimento de um projeto e/ou manutenção. Toda documentação técnica e gerencial de um projeto e/ou manutenção produzida durante o processo de desenvolvimento é mantida pelas áreas de desenvolvimento em repositório oficial. Os artefatos técnicos dos sistemas (ATS) são mantidos durante todo o ciclo de vida, pois registram a inteligência do sistema e serão utilizados e atualizados em todas as ma nutenções e evoluções futuras.
Figura 5. Fluxo dos Controles Institucionais
Edição 69 - Engenharia de Software Magazine
41
Para a construção são utilizadas ferramentas homologadas pela empresa, a fim de possibilitar a integração dos modelos e a visão sistêmica dos negócios. Ao longo do projeto/serviço, sempre que necessário, é refinado e validado junto às equipes. A integridade dos artefatos técnicos de sistema com os requisitos é sempre mantida. Todo projeto/manutenção tem um responsável pela gerência das diversas disciplinas/áreas envolvidas, a fim de estabelecer e manter a integridade dos produtos ao longo do ciclo de vida. Além disso, deve-se promover a prática do paralelismo de atividades. Ao longo do projeto e/ou manutenção compete ao líder de projeto, ou a quem ele delegar, acompanhar e revisar os resultados e as realizações do projeto, comparando o realizado com o previsto nos planos, acordos e estimativas documentadas. Nesse acompanhamento, todos os planos do projeto são atualizados e os compromissos assumidos revisados, sempre que necessário independente da atividade. O objetivo é possibilitar que ações efetivas sejam tomados para evitar que o projeto desvie significativamente dos planos ou que os planos se tornem obsoletos. Em qualquer etapa ocorrem novas validações/aprovações sempre que algum produto, para o qual existam validações/aprovações previstas, for atualizado. Os parceiros e o gestor da informação são informados sobre a situação do projeto e/ou sua manutenção, por meio de pontos de controle estabelecidos em cronograma, independente da ocorrência de alterações. A gestão de projetos de software tem buscado, através de indicadores de desempenho estipulados pela instituição, a constante melhoria em seus processos, principalmente os associados às entregas dentro do prazo estipulado.
42
Referências: 1. AUGUSTINE, S.; PAYNE, B.; SENCINDIVER, F.; WOODCOCK, S. (2005). Agile Project Management: Steering from the Edges. Communications of the ACM, v. 48, n. 12, pp. 85 - 89. 2. Mary Beth Chrissis, Mike Konrad and Sandy Shrum, CMMI: Guidelines for Process Integration and Product Improvement, Addison-Wesley Pub co, 2003. 3. CMMI Model Componentes Derived from CMMI – SE/SW, Version 1.0 Technical report CMU/SEI-00-TR24. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000. 4. CURTIS, Bill; STATZ, Joyce. Building the case for software process improvement. In: SEI NATIONAL CONFERENCE SOFTWARE ENGINEERING PROCESS GROUP, 1996, Atlanta. Proceeding…Atlanta, 1996. 5. DeMarco, T. Structured Analysis and System Specification. Prentice-Hall, 1979.
Você gostou deste artigo? Dê seu voto em www.devmedia.com.br/esmag/feedback Ajude-nos a manter a qualidade da revista!
Engenharia de Software Magazine - Gestão de Projetos: Usando processos de desenvolvimento
Engenharia Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros
ITIL: Como implantar o gerenciamento de mudanças Fique por dentro:
Cristiane Aparecida Lana
[email protected]
Mestranda em Ciência da Computação pela Universidade Federal de Viçosa (UFV). Especialista em Gestão Estratégica de Pessoas pela FACISA - UNIVIÇOSA (2012) e Bacharel em Sistemas de Informação pela Faculdade de Viçosa (2008). Atualmente atua como orientadora de trabalhos de Graduação na Faculdade de Viçosa e pós-graduação Lato Senso pela FACISA - UNIVIÇOSA. Tem experiência na área de Sistemas de Informação com ênfase em Engenharia de Software, Engenharia de Requisitos e Representação do Conhecimento, Sistemas de Apoio à Decisão e Gestão de Pessoas.
Bruno Torres Satler
[email protected]
Mestre em Ciência da Computação - Engenharia de Software pela Universidade Federal de Viçosa (2010). Bacharel em Ciência da Computação pela Universidade Federal de Viçosa (2007). Consultor implementador Melhoria de Processo de Software - MPS-Br. Professor Assistente - FDV Faculdade de Viçosa.Professor Assistente - FACISA Univiçosa.Gerente de Projetos e Analista de Processos - Cientec Consultoria e Desenvolvimento de Sistemas. Professor da pós-graduação Lato Sensu em Sistemas de Informação - FACISA-Univiçosa. Professor da pós-graduação Lato Sensu Especialização em Sistemas para Internet - UFV.
A
complexidade dentro da área de Tecnologia da Informação (TI) é crescente. Juntamente, os números de mudanças oriundos das alterações do mercado, das tecnologias e das necessidades dos próprios clientes e até mesmo da organização, vem aumentando proporcionalmente. Com essa constante transformação a TI precisa ser dinâmica, eficaz e eficiente e os serviços relacionados precisam ser oferecidos com qualidade, de forma estável e confiável. Porém, o conhecimento detalhado e a identificação das mudanças não é uma tarefa simples de ser executada por Microempresas e Empresas de Pequeno Porte, que muitas vezes demonstram falta de estruturação dos processos e pouco conhecimento de metodologias de governança de TI. Os serviços de TI podem ser vistos como um conjunto de recursos, TI e não TI, mantidos por um provedor de TI, cujo
Este artigo analisa o processo de Gerenciamento de mudança da biblioteca ITIL (Information Technology Infrastructure Library), elencando os impactos e benefícios de sua implantação em Microempresas e Empresas de Pequeno Porte de Tecnologia da Informação. A ITIL fornece um conjunto coerente e compreensivo de melhores práticas para gestão de serviços de TI, provendo qualidade técnica para realizar negócios com eficiência e efetividade no uso de sistemas da informação. Este artigo é útil para organizações que desejam implantar ou aprimorar o processo de gerenciamento de mudanças utilizando as boas práticas da biblioteca ITIL. Sua utilização irá assegurar que os processos sofram modificações planejadas, garantindo menor impacto nos serviços/processos que passarão por modificações.
objetivo é satisfazer uma ou mais necessidades da área de negócio e suportar os objetivos estratégicos do negócio da organização e do cliente. Porém, para que a TI satisfaça as necessidades da organização é preciso que ocorra um alinhamento entre os recursos tecnológicos da TI com os
Edição 69 - Engenharia de Software Magazine
43
interesses da organização, onde um complemente o outro no alcance de seus objetivos e principalmente no comprimento da sua missão da organização. Para que este alinha mento ocorra é necessário que a TI forneça serviços que estejam de acordo com as necessidades estratégicas do negócio. Com isso, a TI confronta as limitações ligadas às próprias operações do negócio e respondendo com inovações que sejam ao mesmo tempo eficientes e estratégicas. Com esse alinhamento, a TI passa a ser considerado um parceiro estratégico dentro da organização, se tornando um diferencial competitivo da empresa. Assim, a governança de TI deixa a condição de desejável para o status de essencial aos negócios da empresa. Devido a isto, os auditores das corporações passaram a adotar algumas metodologias de governança de TI, como a metodologia ITIL – Information Technology Infrastructure Library, com a finalidade de melhorar o desempenho desta área. O ITIL foi desenvolvido na década de 1980, pelo Office Government of Commerce Britsh - OGC, inicialmente como um guia do governo britânico para gestão de serviços. Com suas evoluções, atualmente a ITIL é parte da norma ISO 20000 (international Organization for Standardization, ou Organ ização Internacional para Padronização), um padrão internacional para gestão de serviços de TI. A ITIL fornece um conjunto coerente e compreensivo de melhores práticas para gestão de serviços de TI, provendo qualidade técnica para realizar negócios com eficiência e efetividade no uso de sistemas da informação. As práticas desta metodologia são baseadas na experiência de empresas comerciais e governamentais de todo o mundo, as quais têm se tornado cada vez mais dependente de TI. Uma mudança pode aparecer devido a um incidente ou devido a ações proativas para beneficiar o negócio da organização, como a redução de custos ou a melhoria dos serviços. Seu gerenciamento procura minimizar o impacto das mudanças causadas por incidentes e melhorar as operações da organização através das mudanças proativas. Para isso, padroniza métodos e procedimentos para u m controle eficiente das mudanças.
Gerenciamento de Serviços de TI Antes de iniciar o processo de gerenciamento de serviços de TI é preciso garantir o alinhamento entre o que será oferecido pela TI com o negócio da organização. Essa tarefa não é simples, pois é necessário garantir alinhamento estratégico visando a geração de valor para a organização, maximi zando o aproveitamento de novas oportunidades e a redução dos custos. Diante dessa necessidade, a área de TI precisa entender que os clientes atuais querem mais que produtos, eles querem serviços que agregam valor. Sendo assim, a área de TI precisa ir além de prestação de serviço entregue às organizações, ela precisa determinar qual o valor do serviço perante a estratégia de negócio, garantir que os serviços serão entregues dentro do padrão de qualidade exigido pelos clientes e pelos usuários. A Tabela 1 mostra os principais conceitos que foram modificados e quais estão vigentes no cenário atual.
44
Cenário Anterior
Cenário Atual
Atendimento do usuário
Atendimento ao cliente
Perspectiva interna
Perspectiva externa
Esforço pessoal
Esforço repetitivo e medido
Foco na tecnologia
Foco no processo
Processos ad-hoc
Processos racionalizados
Recursos internos
Recursos racionalizados
Comportamento reativo
Comportamento proativo
Visão fragmentada
Visão integrada
Sistema manual
Sistema automatizado
Gestor de operações
Gestor de serviços
Tabela 1. Modificações entre o cenário anterior versus o atual
Para que as modificações dos cenários ocorram com sucesso é necessário que aconteça uma modificação, uma transformação das convicções, do conhecimento e até mesmo da expect ativa do profissional de TI, o que pode proporcionar uma mudança de comportamento e maior comprometimento. O Gerenciamento de serviços de TI é uma série de conceitos que identificam e inter-relacionam as várias atividades envolvidas no desenvolvimento de um ambiente que produz melhoria, métricas e entrega de serviços de TI para os clientes e para a comunidade de usuários de TI. Ele integra pessoas, processos e tecnologias necessárias na busca de viabilizar a entrega do serviço de TI garantindo o alin hamento estratégico de negócio da organização. Contudo, é de extrema importância para as organizações saber de onde estão saindo e onde querem chegar e como chegar. A Figura 1, conhecida como “Fronteira da Eficiência”, mostra o curso do processo onde existe um ponto de saída (ponto A) e um ponto de chagada desejado (ponto A), para se locomover de um para o outro de forma apositiva é necessário manter a prestação de serviço em um nível elevado com um baixo custo. É esse equilíbrio aliada as estratégias e metas que fará com que a organização saía de um gerenciamento de serviços caótico para um equilibrado.
Figura 1. Fronteira de Eficiência
Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanças
ENGENHARIA
O gerenciamento de mudanças pode ser aplicado a qualquer tipo de organização, pequena ou grande, pública ou privada, com serviços de TI, centralizado ou descentralizado, interno ou outsourced, permitindo coordenar o fornecimento e suporte de serviços de TI destinados a preencher as necessidades da organização. Além disso, a abordagem mais conhecida para se fazer o gerenciamento de serviços em TI é a ITIL, pois esta explora as relações entre as atividades nos processos pertinentes a qualquer organização.
Information Technology Infraestructure Library - ITIL A ITIL (Information Technology Infrastructure Library) é um conjunto de padrões de melhores práticas para o gerenciamento de serviços de Tecnologia da Informação. Esta metodologia oferece uma descrição detalhada das importantes práticas de TI, incluindo checklists, tarefas, procedimentos e responsabilidades. Estas práticas são definidas como processos e podem ser adaptadas a qualquer organização de TI cobrindo a maioria de suas atividades. Criada na década de 80 pelo Centro de Computadores e Agência de Telecomunicações – CCTA do Reino Unido, atualmente conhecido como Office of Governamment Commerce – OGC, teve por objetivo padronizar e comparar as diversas propostas de prestadores de serviços de TI ao governo Britânico. A metodologia foi desenvolvida a partir de pesquisas realizadas por consultores, especialistas e doutores na área, para desenvolver as melhores práticas para a gestão de TI nas empresas públicas e privadas. Seu foco está na descrição dos processos necessários para gerenciar eficientemente e eficazmente a infraestrutura de TI garantindo os níveis de serviço acordados com os clientes internos e externos. Na década de 90, a ISO 9000 e o modelo de referência da EFQM (European Fountation for Quality Management) passam a adotar as melhores práticas da ITIL tornando-a um padrão mundialmente conhecido e a metodologia de serviços de TI mais utilizada. A Figura 2 apresenta
Figura 2. Processo do ITIL
os processos do ITIL subdivididos em: Gerenciamento de Aplicações, Gerenciamento de Serviços, Gerenciamento da Infraestrutura, Gerenciamento de Canais de Suprimento, Gerenciamento de Segurança e Gerenciamento de Infraestrutura de Tecnologia de Comunicações e de Informação (TCI). Como pode ser visto na figura, além da definição do negócio, dos parceiros e da tecnologia a ser usada ou implementada, existem diversos processos que devem ser analisados e implementados que são indispensáveis para o sucesso do processo. Além do processo de Gerenciamento de Mudanças, que abordaremos neste artigo, a ITIL conta com mais dez processos que podem ser implementados de forma isolada nas organizações, são eles: 1. Service Desk: ponto único de contato entre usuários/clientes e o departamento de TI; 2. Gerenciamento de Problemas: responsável por minimizar a interrupção nos serviços de TI por meio da organização dos recursos para solucionar pro blemas de acordo com as necessidades de negócio, prevenindo a recorrência e garantindo o registro de informações que melhore a maneira pela qual a organização de TI trata os problemas, resultando em níveis mais altos de disponibilidade e produtividade;
3. Gerenciamento de Configuração:
responsável por fornecer à organização de TI um controle maior sobre todos os seus ativos; 4. Gerenciamento de Incidente: seu foco principal é restabelecer o serviço o mais rápido possível, minimizando o impacto negativo no negócio; 5. Gerenciamento de Liberação: responsável pela implementação das mudanças no ambiente de infraestrutura de TI; 6. Gerenciamento do Nível de Serviço: é responsável por gerenciar o nível dos serviços prestados pela equipe de TI, com o objetivo de definir o tempo de resolução para cada solicitação realizada pelos clientes e tempo para restabelecimento de cada indisponibilidade ocorrida na operação; 7. Gerenciamento de Capacidades: desenhado para assegurar que a capacidade da infraestrutura de TI esteja alinhada com as necessidades do negócio; 8. Gerenciamento de Disponibilidade: visa otimizar a capacidade da infraestrutura de TI ajudando a organização a entregar um nível sustentado de disponibilidade a um custo aceitável, garantindo que os serviços estarão à disposição dos clientes e usuários sempre que for preciso e permitindo assim que os objetivos do negócio sejam alcançados; 9. Gerenciamento da Continuidade dos Serviços de TI: tem por objetivo
Edição 69 - Engenharia de Software Magazine
45
suportar de forma geral o Gerenciamento de Negócios, assegurando que os requisitos técnicos da TI e facilidades de determinados serviços possam ser recuperados dentro de escalas de tempo requeridas e acordadas; e 10. Gerenciamento Financeiro: é responsável por determinar o verdadeiro custo de todos os serviços de TI e demonstrá-lo de maneira que a organização possa entendê-lo e utilizá-lo para o processo de tomada de decisão. Fica fácil entender que as melhores práticas adotadas pelo ITIL abrangem todas as atividades da área de TI. Usando uma abordagem de processo, a ITIL define principalmente o que deve ser incluído no Gerenciamento em Serviços em TI para que se ofereça um serviço de qualidade (veja a seção Links).
Gerenciamento de Mudanças Comumente, as mudanças surgem como resultado para os problemas, embora muitas mudanças possam ser efetivadas com o objetivo de trazer benefícios empresariais ou melhorar os serviços oferecidos. A finalidade da realização do processo de Gerenciamento de Mudanças é alcançar esses objetivos unificando métodos e procedimentos com o intuito de controlar e manipular de forma eficiente todas as mudanças, minimizando o impacto de incidentes que já tenham sido vivenciados anteriormente, e consequentemente melhorar as operações do dia a dia da organização. O aumento da importância da área de TI vem crescendo aceleradamente e junto com ela as exigências de qualidade, redução de tempo de atendimento e custo, etc. visando alcançar os objetivos do negócio. Dentro deste contexto, é preciso vislumbrar uma forma de acompanhar as mudanças da área de TI e a evolução do cenário de negócios. Todas as mudanças, incluindo as de emergência e aplicação de patches, relacionadas à infraestrutura e aplicações dentro do ambiente de produção, devem ser gerenciadas formalmente de maneira controlada. Estas mudanças (incluindo procedimentos, processos, sistemas e parâmetros de serviço) devem ser registradas, avaliadas e autorizadas a ntes da implementação. O Gerenciamento de Mudanças é considerado um tanto quanto burocrático. Isso se deve a exigência de todos os incidentes ser identificados, antes de serem corrigidos, devem ser filtrados, analisados e testados para depois ser implementada as correções no ambiente de produção. Para isso, se faz necessário uma mudança de cultura e um comprometimento de todos para o processo lograr êxito. Sua missão é gerenciar todas as mudanças que de alguma forma possam causar impacto na entrega de serviços pela área de TI, através de um processo único e centralizado de aprovação, programação e controle da mudança, assegurando que a infraestrutura e a área de TI permaneçam alinhadas aos requisitos do negócio, com o menor risco possível. A seguir estão listados os principais objetivos do Gerenciamento de Mudanças, de acordo:
46
• Garantir a utilização dos métodos padronizados para o
tratamento eficiente de todas as mudanças, reduzindo seus riscos e impactos; • Minimizar o surgimento de incidentes que tenham relação
com alguma mudança; • Realizar o balanço entre a necessidade e o impacto.
Segundo a própria OGC, este processo tem foco nas mudanças que afetam Hardware, Software, Equipamentos e Software de Comunicação; aplicações em produção e toda documentação e procedimentos associados com a operação, suporte e manutenção da Infraestrutura de TI. Além disso, ficam fora do escopo do gerenciamento, mas relacionados com este as mudanças em projetos; a identificação de componentes afetados na mudança ou atualização de registro (Gerenciamento de Configuração) e a liberação de novos componentes (Gerenciamento de Liberações). A Solicitação de Mudança (Request for Change – RFCs) é o ponto de partida de todo o processo de Gerenciamento de Mudança. Ela consiste da solicitação inicial da mudança, por parte dos usuários, áreas de negócio e membros das equipes dos processos de Gerenciamento de Incidente e de Gerenciamento de Problema, sendo estes dois últimos os principais promotores de mudanças em um ambiente de infraestrutura de TI. Todas as mudanças devem ser revistas após um período pré-estabelecido a fim de garantir que os resultados foram alcançados e analisar o grau de eficiência na estimativa de recursos utilizados.
Benefícios do sistema de Gerenciamento de Mudanças Os benefícios específicos do processo de Gerenciamento de Mudanças descritos pela ITIL são: • Melhor alinhamento dos serviços de TI com os negócios. • Aumento da visibilidade e comunicação das mudanças entre
seus atores. • Melhoria no processo de avaliação de riscos, reduzindo o
impacto negativo da mudança. • Melhor avaliação de custos das mudanças. • Redução do número de mudanças que necessitem da execu-
ção dos seus planos de retorno ao original (backout). • Melhor identificação dos problemas. • Aumento na produtividade dos usuários, com a redução das
paradas de serviços de TI. • Aumento de produtividade de pessoal da área de TI, pela
maior fidelidade às ações que são planejadas. • Habilidade de absorver um grande volume de mudanças. • Um aumento da percepção dos valores do negócio, por parte
da equipe de TI, resultando em melhoria na qualidade dos serviços de TI.
Detalhamento do Processo O processo de Gerenciamento de Mudanças é responsável por decidir e coordenar as mudanças não tendo como objetivo direto executar a implementação. A implementação será realizada
Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanças
ENGENHARIA
por uma equipe técnica responsável pela área de mudança, como a área de redes, sistemas, hardware. Este processo controlará as mudanças para que elas sejam implementadas de forma eficaz, no que se refere ao custo, com um mínimo de riscos para os serviços mantidos. Para a elaboração de uma análise de riscos adequada é importante o uso de uma Base de Dados do Gerenciamento de Configuração, pois este irá fornecer todos os serviços e recursos relacionados ao item de configuração que sofrerá a mudança. As principais entradas e saídas do processo de Gerenciamento de Mudanças são mostradas na Figura 3. Como pode ser visto na figura, as principais entradas dos processos RFCs (Request for Change) é o Requisições de Mudanças - RDM, FSC (Forward Schedule of Changes) é a Programação Futura de Mudanças - PFM, o agendamento das próximas mudanças; e por fim o CMDB que recebe informações do processo de Gerenciamento de Capacidade, Configuração e Liberações para realizar a análise de riscos, planejamento e custos. No que tange às saídas tem-se a PFM – Programação Futura de Mudanças, RDM – Requisições de Mudanças Aprovadas e Atas da Reunião do CCM – Conselho de Controle de Mudanças. Apesar do Gerenciamento de Mudança possuir uma estrutura sólida, não é possível que ele seja implementado sem considerar o entorno, principalmente os projetos que podem sofrer alterações ao longo de seu percurso. Sendo assim, a Figura 4 mostra como ocorre a interação entre o Gerenciamento de Mudanças e o de Projetos. É possível perceber que em todas as fases do projeto podem ocorrer mudanças e que o gerenciamento intervém de forma a minimizar os impactos e controlar os pontos de mudanças existentes que modificaram o projeto original.
Registro de Requisição de Mudança – RDM O Registro de Requisição de Mudanças (RDM) pode ser levantado a partir de uma necessidade do setor de TI, ou surgir em virtude de um erro identificado
Figura 3. Entradas e Saídas do Processo de G erenciamento de Mudanças
Figura 4. Integração dos Processos de Gerenciamento de Mudanças e Gerenciamento de Projetos
em processos anteriores, como o Gerenciamento de Problemas, por exemplo. A RDM poderá ser em papel ou eletrônica através de algum software de Gerenciamento de Serviços. • Registro e Classificação
Diversas informações para a tomada de decisão devem estar contidas em um RDM, tais como categoria, impacto e custo. A partir destas será elaborado o relatório gerencial e a cada mudança deve ser associada ou alocada sua prioridade para definir a agenda de mudanças programadas.
• Aprovação
Todos os RDMs devem ser filtrados e aprovados mas alguns fatores podem determinar que uma mudança seja recusada, por exemplo, se o custo da mudança é mais alto que o benefício que ela pode oferecer. • Coordenação do Desenvolvimento
Após aprovada a mudança, a RDM deve ser passada a um grupo técnico que será responsável pelo desenvolvimento da mudança. O Gerenciamento de Mudanças deve coordenar todo este processo, garantindo assim, a existência
Edição 69 - Engenharia de Software Magazine
47
dos recursos necessários, monitorando os riscos e acompanhando os testes. • Autorização e Implementação
Após passar pela fase de desenvolvimento, as mudanças devem ser testadas antes de ir para o ambiente de produção. É aconselhável que exista um grupo de testes independente neste processo, que tenha condições técnicas para elaborar o plano de testes avaliando todos os requisitos para o funcionamento da mudança no ambiente de produção e só após o resultado dos testes que a mudança será autorizada para ser implementada. • Implementação
O Gerenciamento de Mudanças deve garantir que as mudanças sejam implementadas seguindo um programa definido. A execução da implementação não é de responsabilidade deste processo, ficando o seu cargo apenas a coordenação. O processo de Gerenciamento de Liberações poderá ser coordenado pelo processo de Gerenciamento de Mudanças, pois as mudanças de fato acabam gerando novas liberações de software ou de hardware. • Avaliação
O Gerenciamento de Mudanças deve avaliar todas as mudanças implementadas depois de determinado período, chamada de Revisão Pós-Implementação. O processo de Gerenciamento
de Problemas também pode vir a acompanhar este processo. Esta revisão se destina a verificar se a mudança trouxe os resultados esperados, ou caso haja algum problema ou ineficiência, ações devem ser tomadas para a sua correção. A Figura 5 mostra o fluxograma que explica o que ocorre numa RDM, mostrando o inicio da requisição ate a avaliação final fechando a mudança requisitada.
Comitê de Controle de Mudança – CCM O Comitê de Controle de Mudança (CCM) é responsável pela avaliação do impacto das mudanças. Este grupo será composto de pessoas técnicas e até mesmo clientes, que fornecerão assessoria ao Gerente de Mudanças sobre quais mudanças devem ser aprovadas e auxiliarão na programação das mudanças. Normalmente, o CCM se reúne com uma determina frequência para discutir todas as mudanças novas e que ainda estão em andamento.
Comitê de Emergência – CCM/CE Quando surgem problemas mais graves é necessário identificar uma configuração menor com autoridade para tomar decisões emergenciais, pois pode não haver tempo para se criar um CCM completo, sendo o presidente deste comitê o Gerente de Mudanças, que são os técnicos responsáveis pela implementação da mudança. Dependendo da criticidade da mudança, é determinada por essa equipe uma rápida alteração no ambiente para que a solução seja imediata.
Figura 5. Exemplo do processo de Gerenciamento de Mudança
48
Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanças
ENGENHARIA
Programação de Futuras Mudanças – FPM A Programação Futura de Mudanças (FPM) é responsável por manter atualizados os detalhes de todas as mudanças que têm sido autorizadas para implementação dentro de um período previamente estabelecido, ou seja, o cronograma para alteração no ambiente equivale ao grau de risco que a mudança pode oferecer. Se a mudança tiver um nível crítico muito alto, o tempo para planejamento será maior. Um bom exemplo seria uma empresa que por problemas técnicos precisa trocar o seu servidor, e Figura 6. Relacionamento do processo de Gerenciamento de Mudança com outros processos da ITIL no momento da troca serão desligados todos os computadores, neste caso, serão envolvidas várias garantir que ele reflita os objetivos organizacionais, além de áreas da empresa, tais como: infraestrutura e TI. Haverá um serem quantificáveis (veja a seção Links). tempo para cada área planejar sua execução, no entanto um Problemas Potenciais do Gerenciamento de Mudanças tempo maior é exigido para execução da Mudança. A seguir, estão descritos possíveis problemas que podem ser enfrentados pelo processo de Gerencia mento de Mudança: Relacionamento com outros Processos O processo de Gerenciamento de Mudanças está relacio- • O escopo de uma mudança pode ser muito grande para os nado com outros processos da ITIL, como pode ser visto na recursos disponíveis, pode sobrecarregar os recursos e gerar dependência da precisão dos dados de configuração com a atrasos; • Falta de clareza nas propriedades dos sistemas impacprecisão do processo de Gerenciamento de Liberação para assegurar o conhecimento sobre o impacto completo em se tados; • Caso o processo de Gerenciamento de Mudanças seja impleaplicar a mudança no ambiente de trabalho. Outros processos podem relacionar-se com o Gerenciamento mentado sem o processo de Gerenciamento de Configuração, de Mudanças, pois eles podem requisitar também mudanças possivelmente a solução será menos efetiva; • A burocratização do processo, fazendo com que não seja (Gerenciamento de Disponibilidade) ou podem ser consultados para determinar o impacto da mudança (Gerenciamento seguido; da Continuidade dos Serviços de TI, Gerenciamento do Nível • Dados sobre os CIs (Itens de configurações) incorretos podem de Serviço e Gerenciamento da Capacidade - Figura 6). resultar em avaliação de impacto incorreta; • Deficiência na atualização entre plataformas e localidades faz A Figura 6 mostra que o processo de mudança ocorre de forma interativa, sendo que a qualquer momento pode surgir com que seja difícil ou quase impossível agendar mudanças; uma necessidade específica nos mais diferentes módulos do • Procedimentos de contingência que não existem ou não processo geral do ITIL e este deve ser analisado e suprido de foram testados; • O acompanhamento de progresso das mudanças é manual, acordo com as diretrizes aprovadas pela organização. o que gera sobrecarga em quem o executa;
Indicadores de Desempenho – KIP (Key Performance Indicator)
O processo de Gerenciamento de Mudanças deve conter mecanismos de controle que permitam avaliar sua eficiência, eficácia, efetividade e economicidade. Para isso, são utilizados os Indicadores de desempenho, também chamados de Indicadores Chave de Desempenho (ou Key Performance Indicator – KPI – em inglês) que servem para avaliar e medir o nível de desempenho de processos chaves para a empresa. O KIP é uma medida quantificável que tem como função refletir os fatores críticos de sucesso da organiz ação que varia de uma organização para outra. Uma empresa pode ter como KIP os percentuais de sua receita que vem do retorno dos clientes, uma escola pode set seu KIP no número de alunos graduados, etc. Independente do KIP selecionado é preciso
• As faltas de acompanhamento da alta e média gerência fazem
os tempos de implementação crescer, e há uma resistência aos novos controles, a menos que veja comprometimento dos gerentes; • Mudanças de emergência frequentemente provocam a falha
do processo
Detalhamento das Fases As mudanças podem ocorrer de forma programada, acelerada ou emergencial. Para efeito de definição, mudanças “Programadas”, “Aceleradas” ou “Emergenciais” seguem o mesmo procedimento, sendo que, os parâmetros de tempo devem atender as necessidades específicas de cada tipo. A programada exige um conhecimento prévio da necessidade não exigindo urgência para sua execução. Edição 69 - Engenharia de Software Magazine
49
Portanto, segue o processo normal de Gerência de Mudanças. Aceleradas, as mudanças que necessitam ser executadas o mais rápido possível seguindo o processo normal da solicitação, por necessidade técnica ou de negócios da empresa estudada. Emergencial, a mudança vital para atender uma necessidade de negócio, normalmente para correção de um problema, e que não pode aguardar o processo normal de mudanças, particularmente na revisão e fase de aprovação, onde existe o risco iminente para os negócios, ativo ou processos da empresa estudada Qualquer evento que ocorra no ambiente de tecnologia e que não possua uma “Mudança” registrada deve ser enquadrado como “Incidente Técnico” não controlado e o processo de comunicação devem abranger as áreas de negócio de toda a empresa estudada. A metodologia recomentada pela ITIL para realização do processo de melhoria contínua dos serviços de TI é PDCA ((P(Plan = Planejar) D(Do = Executar) C(Check = Verificar) A (Action = Agir)) que se baseia no controle de processos. Desenvolvido na década de 30 e utilizado pela indústria manufatureira, o PDCA é composto por quatro passos: 1) Plan – Planeja as ações a serem executadas; 2) Do – realiza as ações que foram planejadas; 3) Check – Verifica se o que foi feito esta de acordo com o planejado; e por fim 4) Act – que Atua corretivamente sobre a diferença identificada. Seu maior objetivo é manter os clientes e mantê-los satisfeitos.
Descrição do Estudo de Caso : A organização Para análise do processo de gerenciamento de mudanças, buscou-se um estudo de caso: uma Empresa de Pequeno Porte do ramo de tecnologia de informação situada na Zona da Mata Mineira. Sua missão é Transformar conhecimentos gerados em universidades e centros de pesquisas em soluções para a sociedade e assim busca ser reconhecida pelo mercado como empresa inovadora que desenvolve produtos e soluções c om qualidade mundial. Fundada em 1997 na incubadora da base tecnológica do CENTEV da Universidade Federal de Viçosa (MG), a empresa se posiciona no mercado como um elo importante entre a pesquisa científica e a sociedade, buscando propor soluções para o gerenciamento de informações para diversos profissionais que buscam a otimização do tempo e capacitação profissional de qualidade. Na busca de melhorar a qualidade de seus produtos e serviços e desejando aprimorar, a cada dia seus conhecimentos, a empresa implantou o programa “SEBRAE de Gestão da Qualidade (PSGQ)”, processo no qual obteve 100% de aprovação. Em 2010, a empresa passou por novas expansões, iniciando o desenvolvimento de cursos online para capacitação profissional em diversas áreas de atuação, aplicativos móveis e formando uma importante parceria com a empresa Aoki Sistemas para a comercialização do E2corp, que é um promissor Sistema de Gestão Empresarial (ERP - Enterprise Resource Planning). Com o sucesso dos cursos online, a empresa iniciou, em 2012, o desenvolvimento e comercialização de e-books, contando
50
com parcerias para distribuição nacional e internacional. Após 15 anos de existência, a empresa vem fidelizando, de forma progressiva, seu mercado consumidor e sua linha de produtos, oferecendo sempre aos seus clientes produtos de qualidade e que os auxiliem em sua trajetória de sucesso.
Cenário Atual Atualmente a empresa possui um gerente para cada setor (administrativo, vendas, suporte pós-vendas, departamento de TI e nutricional) e um gerente geral. Toda e qualquer solicitação de mudanças é feita sem passar por qualquer processo. O solicitante interessado em um a mudança entra em contato com o membro da equipe de TI e informa seu interesse solicitando sua execução. Este procedimento em sua maioria das vezes acarreta a realização de mudanças sem retorno e com altos índices de impactos negativos. Tais solicitações por serem feitas sem nenhum monitoramento, podem propiciar o não atendimento de uma mudança que seja prioritária para a organização, por exemplo, para a organização em análise todas as aplicações web são de fundamental importância, tais como: instabilidade do servidor, necessidade de melhoria de uma aplicação para atendimento de um dado setor, como busca e listagem de cursos no sistema. Contudo, por não possuírem um sistema de gerenciamento de mudanças a aplicação web pode deixar de ser atendida em detrimento de outra solicitação de menor importância. Isso ocorre porque não existe nenhum software de controle de solicitações implantado. Assim, as solicitações de mudança chegam por e-mail, telefone ou por meio do famoso “boca a boca”, que na maioria não ficam registrados, afetando o planejamento do gerente de projetos, gerente de TI que somente fica sabendo que a solicitação existe após a sua execução. Desta forma, os problemas que existem no cenário atual são: • Ausência de documentação para formalizar uma solicitação
de mudança; • Descentralização das solicitações de mudanças; • Ausência de filtro de prioridade para execução de
mudanças; • Falta de prazo limite para aprovação da solicitação.
Gerenciamento de Mudança na Organização O processo de Gerenciamento de Mudança na organização tem por objetivo manter o controle das mudanças na área de TI, de uma forma documentada, processual e controlada, visando minimizar ao máximo os impactos negativos. Com isso, faz-se necessário o apoio de um processo de Gerenciamento de Configuração eficiente, que ofereça uma CMDB (Banco de Dados do Gerenciamento da Configuração) atualizada, uma vez que o registro dos CIs (Item de Configu ração) compõem quais serviços de TI são de responsabilidade daquele processo. Analisando a empresa, verificou-se que a mesma possui um software para a realização das interações pertinentes aos processos, chamado de Help Desk. Todos os setores da empresa podem se comunicar através desse software com envio de chamados específico para cada setor. Porém, atualmente a
Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanças
ENGENHARIA
organização não possui um Service Desk estruturado, ficando sem um ponto central de contato entre os usuários e a área de TI. O objetivo do processo é definir os papéis e responsabilidades, processos e o fluxo padrão a serem utilizados para todas as solicitações, para que haja o controle integrado de mudanças. O controle integrado de mudanças compreenderá a identificação, documentação, análise e autorização das mudanças, tendo como critérios de avaliação para aprovação o escopo, custo de execução e prazo previamente autorizados para cada solicitação de mudanças, sendo classificadas em três tipos de mudanças, normal, padrão e emergencial. A normal é a mudança planejada com antecedência. A padrão por sua vez é uma mudança rotineira e de baixo impacto, por exemplo, a mudança de senhas, alteração de cursos, modificação de arquivos para licitação. Já a emergencial, é aquela mudança vital que surge para atender uma necessidade ou sanar um incidente ocorrido. Esse tipo de mudança não necessita passar pela fase de autorização indo direto para a fase de implementação. O enquadramento de cada solicitação de mudanças auxilia na coordenação da implementação. O plano de gerenciamento de mudanças não tem como objet ivo executar a implementação das mudanças sendo apenas responsável por decidir e coordenar o processo de mudanças. A implementação será realizada pela equipe de desenvolvimento. Assim, é necessário a definição dos papéis e responsabilidades de cada participante da equipe. As solicitações de mudanças devem seguir um roteiro padrão, onde cada solicitante deve registrar sua solicitação por meio de um formulário que por sua vez deve ser enviado ao gerente de mudanças. Neste momento cria-se o registro de solicitação de mudanças – RDM, o qual fica a cargo do gerente de mudanças, atribuir uma identificação única para cada solicitação. O ideal é que esses registros sejam individuais evitando a sobreposição de registros. Na fase de registro e classificação várias informações serão utilizadas para a tomada de decisão, tais como categoria, impacto, custo. Estas informações também serão utilizadas para produzir relatórios gerenciais, onde a RDM será classificada de acordo com a prioridade para cada mudança para definir o tipo de mudança a qual se encaixa. O comitê, por meio do relatório gerencial, deve filtrar a solicitação no início da atividade de classif icação, para saber se a solicitação é pertinente. Caso não seja, será encaminhada para o gerente de mudanças para que possa informar a recusa da solicitação ao solicitante por meio do documento de registro de encerramento da solicitação. Caso a solicitação seja pertinente, o comitê deve classificá-la em um dos três tipos de mudanças: normal, padrão ou emergencial. Após as RDMs serem classificadas e filtradas, elas devem ser aprovadas. Na fase de aprovação o comitê se re úne com o gerente de mudanças para avaliar os possíveis impactos, que podem ser gerados pela solicitação de mudança, baseados em custo, cronograma e escopo para sua realização. Em seguida, a
requisição de mudanças, agora aprovada, chega novamente às mãos do gerente de mudanças que inicia a fase de coordenação e desenvolvimento. Na fase inicial de coordenação e desenvolvimento, deve-se identificar se a RDM tem urgência alta ou impacto mínimo. Caso a RDM se enquadre em uma destas duas formas, a fase de autorização pode ser deixada de lado e passar di reto para a fase de implementação. Toda mudança deve ser testada nas atividades ao final da fase de autorização e na atividade de avaliação, antes de ser enviada para o ambiente de produção. É importante que exista uma equipe de testes para elaboração do plano de testes avaliando o funcionamento após realização da mudança. Na fase de autorização a equipe de testes irá acompanhar como está o planejamento de execução das mudanças e, ao obter resultados satisfatórios por meio de testes, a mudança será autorizada a passar para a fase de implementação que tem como objetivo apenas executar a solicitação de mudanças conforme a coordenação do gerente de mudanças. Nesta fase são gerados os relatórios de testes realizados. O gerente de mudanças irá coordenar a execução durante a fase de implementação, ficando a cargo da equipe de desenvolvimento executar o plano de desenvolvimento informar se existem alterações críticas para que elas sejam autorizadas e novamente implementadas. Não havendo alterações inicia-se a fase de avaliação. A fase de avaliação tem como objetivo, revisar todo o escopo de acordo com o que foi implementado. Assim, será possível verificar se a mudança foi realizada como esperado ou se resultou outros erros inesperados e quais ações a serem tomadas para a correção. Não ocorrendo a rejeição, a mudança entra em produção e é formalizada a entrega da solicitação de mudança como executada e aprovada para o solicitante.
Planejamento de Mudança O primeiro passo do planejamento para implantação do processo de Gerenciamento de Mudanças da ITIL é escrever o documento da metodologia no qual será formalizado: Solicitações de Mudanças, Planejamento das Atividades, Avaliação de Riscos, Avaliação de Impacto, Registro de Envolvidos, Fluxo de Comunicação, Definição e Homologação das Contingências, Definição e Homologação de Planos de Retorno entre outros. Esse documento terá que ser escrito pelo gerente responsável pelas mudanças, juntamente com outros gerentes de outros setores da empresa. Para implantar o plano de gerenciamento, a fase inicia l será composta de reuniões com todos os membros para explicar os objetivos esperados, quais serão os papéis de cada um e suas respectivas responsabilidades, além de inserir o fluxo de gerenciamento de mudanças. Após as definições iniciais, será disponibilizado o treinamento sobre a nova forma de gestão de mudanças, detalhando o objetivo e execução das fase s que compõem cada solicitação de mudanças. O treinamento é importante para que a equipe esteja preparada para receber, registrar e dar prioridade a todas as Edição 69 - Engenharia de Software Magazine
51
requisições de mudanças (RDMs), criar uma agenda de atividades e publicar RDMs para o comitê de controle de mudanças, convocar reuniões de emergência, coordenar a construção, o teste e a implementação das mudanças, manter os registros de mudanças atualizados com o progresso, revisar todas as mudanças implementadas para garantir que tenham atingido seu objetivo, revisar RDMs pendentes para depois fechá-las e finalmente fazer relatórios gerenciais. A ferramenta Help Desk passa a ser utilizada para realizar solicitações de mudanças e planejamento das atividades necessárias para a implementação. É preciso manter de forma controlada todos os registros do planejamento inicial, das dificuldades encontradas, das mudanças de rota e das decisões tomadas (quem, quando, por que). Quanto melhor planejado o projeto, menos problemas e necessidades de revisões futuras, porém dificilmente o projeto será cumprido do início ao fim sem qualquer mudança ou adaptação e por mais insignificantes que pareçam, essas mudanças devem ser documentadas. Definido os papéis de cada integrante da equipe, o plano de gerenciamento de mudanças entra em estado experimental. Neste estado uma grande porcentagem da equipe de TI deverá estar operando de acordo com o novo fluxo de trabalho e a outra porcentagem restante estará executando as atividades remanescentes. O estado experimental irá perdurar até que toda a equipe esteja totalmente alinhada com a nova forma de gestão e os solicitantes já estiverem em um n ível de maturidade suficiente para centralizar suas solicitações apenas para o gerente de mudanças. O risco envolvido no processo de forma geral é uma análise de fundamental importância, onde deve existir um mapeamento de todas as possibilidades de insucesso, pois este documento será utilizado como referência para determinação das contingências necessárias, quanto mais detalhes (sob a perspectiva do negócio) forem catalogados, mais fácil será determinar os riscos envolvidos na operação. A implantação do gerenciamento de mudanças deverá ocorrer em três passos sendo eles: 1. Inserção da cultura organizacional por meio de reuniões; 2. Disponibilizar um treinamento para toda a equipe de acordo o plano de execução de mudanças; e 3. Execução da nova gestão de mudanças em estado experimental com uma parte da equipe até chegar à maturidade suficiente para que toda a equipe esteja alinhada com o gerenciamento de mudanças. A Tabela 2 apresenta o cronograma de atividades de implantação do Gerenciamento de Mudanças na empresa est udada. Para executar cada solicitação de mudanças é necessário seguir os prazos do fluxo de atividades que compõem a terceira fase. A implantação irá ocorrer em três fases, onde o término de uma é o início da outra. Na terceira fase a execução das mudanças irá acontecer em estado experimental durante um tempo pré-determinado.
52
Fases
1- Inserção da cultura organizacional por meio de reuniões diárias.
Período
4 semanas
2- Treinamento da equipe de acordo o plano de execução de mudanças. 3 semanas 3- Execução da nova gestão de mudanças em estado experimental.
12 semanas
Cada solicitação de mudanças percorre as próximas sete atividades
3.1- Registro de Requisição de Mudanças – RDM
Início
3.2- Registro e Classificação
3hs
3.3- Aprovação
3hs
3.4- Coordenação do Desenvolvimento
3h
3.5- Autorização
3h
3.6- Implementação
Depende de cada tipo de solicitação
3.7- Avaliação
24h
Tabela 2. Cronograma de Implantação do Gerenciamento de Mudanças
Assim, após deixar o ambiente estável, pode-se iniciar o segundo passo que poderá ser a implantação do processo de Gestão de Incidente. Depois poderão vir outros processos: Gerenciamento de Problemas, Gestão de Nível de Serviço, Gestão de Configuração, Gestão de Capacidade, Gestão de Disponibilidade, Gerenciamento Financeiro e Gestão de Continuidade dos Serviços de TI. Com a proposta de implantação do gerenciamento de mudanças estima-se como principais benefícios uma melhora no alinhamento das solicitações com o negócio, maior índice de assertividade, maior disponibilidade do tempo da equipe de desenvolvimento, melhora na produtividade, redução de transtornos e serviços de alta qualidade. Estes benefícios podem ser alcançados, desde que sua equipe seja capaz de filtrar e priorizar as mudanças, ocasionando na redução da quantidade de solicitações a serem realizadas. Deste modo estima-se que a disponibilidade da equipe de desenvolvimento irá ser maior possibilitando uma melhora na qualidade dos serviços prestados.
Plano de Reversão Esta atividade deve prever quais passos, se possível, devem ser aplicados para que mudança retorne ao seu estado de origem, ou seja, em uma situação limite onde o procedimento deve ser abortado, o que se deve fazer para minimizar os impactos e “voltar” na situação pré-mudança.
Estimativa de Custos Operacionais A estimativa de custo tem como objetivo mensurar quais custos diretos está envolvido na mudança e os ganhos financeiros, se existirem.
Classificação dos Resultados Quanto aos resultados, o gerenciamento da mudança pode ser classificada em: • Sucesso: Quando a mudança foi bem sucedida, ou seja, o objetivo proposto foi alcançado dentro do tempo planejado.
Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanças
ENGENHARIA
• Impacto: Quando a mudança foi realizada, no entanto, ultra-
passou o tempo planejado, causando impacto para o mesmo. • Falha: Quando a mudança não pôde ser concluída devido a algum problema durante sua execução e que a mudança foi abortada, porém dentro da janela acordada com o c liente.
Prevenção As prevenções que seguem são fundamentais para a definição do escopo do Processo Gerência de Mudanças: • Cabe ao Solicitante da mudança fazer seu planejamento
discutidas com mais detalhes. Estando a mudança acordada na reunião, será buscada a aprovação formal dos coordenadores. Essa aprovação significa que a mudança foi negociada e autorizada, sendo assim cabe ao Coordenador de Mudanças da empresa que será o gerente de Projetos que também é o gerente de TI, aprovar somente as mudanças requisitadas pelos analistas e/ou outros solicitantes e ao Coordenador Geral da empresa que será o gerente geral, sinalizar que a mudança foi negociada.
técnico.
Mudanças Emergenciais
• Quando um pedido de mudança é feito, todas as informações
Desde que sejam registradas adequadamente e negociadas com a Gerência de Mudanças, mudanças de emergência poderão ocorrer a qualquer momento, passando antes por uma triagem onde deverá ser comunicado e esclarecido o motivo da emergência, cabendo ao coordenador avaliar a real necessidade. As responsabilidades do setor responsável pelas mudanças são:
técnicas e de planejamento devem ser acompanhadas desde o início do pedido. • O processo de Gerência de Mudanças não possui envolvimento direto com a fase de implementação da mudança, porém deverá monitorá-la e registrar sua implementação
Aprovação: Processo e responsável Durante a Reunião de mudanças, todas as mudanças apresentadas serão aprovadas ou não pelo grupo técnico participante da reunião. Se não houver o consenso do grupo para sua aprovação, essa mudança será levada para outra reunião mais técnica e específ ica (mudança crítica), onde serão
• Coordenar todas as mudanças solicitadas; • Garantir a existência de planos de retorno para as mudan-
ças; • Em caso de falhas, garantir a implementação do plano de
retorno para as mudanças executadas pela empresa;
Edição 69 - Engenharia de Software Magazine
53
• Aprovar ou rejeitar as mudanças apresentadas que tenham
impacto no negócio, custo ou afetem o ambiente de TI da empresa; • Identificar e informar as mudanças e apresentar as informações necessárias para o seu perfeito entendimento; • Detalhar o cronograma e o planejamento das mudanças; • Produzir toda a documentação necessária para a mudança; • Cancelar ou reprogramar as mudanças quando necessário,
justificando motivo da ação; • Avaliar os impactos das mudanças planejadas junto aos soli-
citantes e representantes técnicos das várias áreas envolvidas, garantindo que todos estejam cientes e em concordância c om a mudança; • Executar as mudanças conforme o cronograma e atividades
definidas pelo solicitante das mudanças; • Fornecer informações sobre qualquer problema ocorrido
durante a execução das mudanças;
de mudança, fazendo com que a equipe da á rea de TI adote um novo comportamento. Assim, a governanç a de TI serve para controlar os objetivos da área de tecnologia, alinha r as estratégias, definir expectativas e medidas de desempenho, viabilizando e gerenciando recursos, definindo prioridades, direcionando as atividades de TI e gerenciando riscos. Para uma implementação eficaz de ITIL, não basta conhecer as melhores práticas, especialmente no que se refere aos benefícios de longo prazo para o negócio e o alcance de uma situação de excelência dentro da organização de TI. Idealmente, uma implementação de ITIL com sucesso significa que as pessoas da organização assimilaram na sua c ultura, os processos e procedimentos da ITIL. O fundamental é que a adoção da ITIL permitirá a adoção de uma cultura de melhoria contínua de qualidade dos serviços prestados pela área de TI que, no mínimo, garantirá a manutenção dos ganhos já obtidos.
• Interagir com o “Solicitante” para garantir que o requeri-
mento de mudança foi atendido, informando-lhe o status final e os detalhes da execução; Referências e Links:
Investimento de Implantação A implantação da metodologia na empresa não terá muitos investimentos financeiros, somente o de implementação e documentação. Os funcionários que irão atuar diretamente na implantação da mudança terão que realizar cursos de certificação ITIL. Esses cursos podem ser feitos online. A empresa pode comprar apenas um pacote de cursos que tem um custo aproximado de R$ 600,00 e colocar os funcionários para realiza r os cursos numa sala usando um Datashow, assim, o gasto será menor. Caso a empresa queira que os funcionários envolvidos tenham a certificação ITIL, terá um gasto de aproximadamente R$370,00 para cada diploma, ou seja, por cada funcionário que realizar a prova de certificação. Observando a grande dificuldade de obtenção de ferramentas e informações para melhor gerir uma organização da área de TI, observa-se a grande importância de se ter um mecanismo eficaz para gerenciar e auxiliar os processos de tomada de decisão. A implementação dos processos baseados na ITIL está relacionada diretamente a um profundo e extenso programa
54
[1] MAGALHAES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de Serviços de TI na Prática: Uma abordagem com base na ITIL. São Paulo. Novatec, 2007. [2] MANSUR, Ricardo. Governança de TI. 2004 http://www.profissionaisdetecnologia.com.br/modules. php?name=News&file=art icle&sid=63 Para mais informações sobre o ITIL http://www.itil-officialsite.com/ Key Performance Indicators http://management.about.com/cs/generalmanagement/a/keyperfindic.htm
Você gostou deste artigo? Dê seu voto em www.devmedia.com.br/esmag/feedback Ajude-nos a manter a qualidade da revista!
Engenharia de Software Magazine - ITIL: Como implantar o gerenciamento de mudanças
Desenvolvimento Nesta seção você encontra artigos voltados para diferentes abordagens de apoio ao desenvolvimento de projetos de software
Boas práticas de programação Fique por dentro:
A
vida de um programador não é fácil. A tecnologia é algo que não para de evoluir e a cada dia surge uma forma diferente de escrever um código. A carreira de um profissional de informática é algo de sua responsabilidade. O código produzido por esse profissional também é de sua responsabilidade. Um bom código não é somente aquele que é funcional, mas também aquele que não tem valores exorbitantes para ser mantido. A maior parte dos programadores não gostam de alterar códigos mal escritos. Isso é algo que traz muita frustração e muitas vezes um retrabalho desnecessário. Leandro Tavares Siciliano
[email protected]
Formado em Análise de Sistemas UNESA com MBA na UFRJ.Experiência de 17 anos de mercado.Atualmente atuando como desenvolvedor desenvolvedor Java e Lotus Notes.Certificações: Certified Lotus Professional e Scrum Master.
Clean Code
• Eficiente: código que faz o que é
proposto; • Sem duplicidade: não faz o que outra
parte do código já faz; • Elegante: porque é diferente dos outros
códigos; • Feito com cuidado: quem fez teve preo-
cupação em produzir aquele código. Antes de falarmos sobre como fazer para atingir esse nível de qualidade, vamos falar um pouco sobre testes.
Importância dos testes
Um código limpo deve ser: • Simples: código fácil de entender; • Direto: vai direto ao ponto, não dá
“voltas” para atingir seu objetivo;
Este artigo apresenta um conjunto de boas práticas de programação com o objetivo de mostrar como pequenas modificações podem ajudar no dia a dia dos programadores e profissionais de TI. As boas práticas aqui apresentadas podem ajudar no desenvolvimento profissional daqueles que trabalham envolvidos em atividades de programação.
Construir um software não é somente escrever código e vê-lo funcionar, é você saber que aquele código será manutenível e que outras pessoas vão alterá-lo.
Edição 69 - Engenharia de Software Magazine
55
Para isso, teste é fundamental! Você tem que ser responsável por aquilo que escreve e saber que seu sistema tem que continuar funcionando. Neste contexto, temos a primeira dica sobre um código limpo: “Toda linha que você escrever deve estar
Listagem 2. Exemplo de declaração considerando boas práticas
public class NotaFiscal { private Date dataCompra; private Date dataVencimento; private boolean isDataVencimentoM aiorDataCompra(){
testada e ponto final !”
Muitas empresas veem testes como gastos maiores no pro jeto, o que de fato acontece, porém a qualidade do software produzido é algo significante. Quando não se produz teste automatizado, a quantidade de testes manuais são maiores e muitas vezes o custo desses testes também é maior.
return dataCompra.after(dataVenciment o); } //getters e setters }
Nomes significativos Métodos, nomes de variáveis e etc. devem possuir nomes que significam alguma coisa em relação ao seu objetivo. Os nomes utilizados devem responder todas as questões a seguir: • Porque existem? • O que fazem? • Como são usadas?
Vamos imaginar que um sistema de um motor de um carro tenha um método com o nome de “run” ao invés de “acelerar”. Se você pegar um código com esse nome você terá que estudar todo o método para saber o que ele faz. Algo muito comum encontrado nos códigos é o tipo de declaração apresentado na Listagem 1. Se um nome de classe, método ou atributo requer um comentário, ele não está revelando sua real intenção.
Evite notação húngara A notação Húngara visa facilitar o reconhecimento do tipo de variável em um programa colocando em seu nome um sufixo descrevendo seu tipo (ver Listagem 3). Entretanto, com o advento de novas linguagens, técnicas mostradas aqui e testes automatizados, a notação húngara se mostra desnecessária. Existe uma certa tendência para a criação de classes e métodos menores de modo que as pessoas possam ver onde cada variável que estão usando foi declarada. Além disso, os testes indicam os tipos e maneiras de usar, validando o comportamento esperado do método. Listagem 3. Exemplo de uso de notação húngara
public class Pessoa { private String nomeString;
Listagem 1. Exemplo de declaração
// Não existe aqui a necessidade de se colocar a palavra ‘String’, // pode-se somente ficar ‘nome’ //getters e setters }
public class NotaFiscal { private Date d1;//Data da compra private Date d2;//Data de vencimento private boolean validaDatas(){ //Valida se data do vencimento
é
maior que a data de compra
if(d1.after(d2))){ return true; } return false; } //getters e setters
}
Quando colocamos uma linha em nosso código com um comentário ao lado não estamos dando o nome correto ao atributo ou método. O código quando bem escrito deve ser algo que seja de fácil leitura, algo que uma pessoa leiga conseguiria ao menos saber o que o mesmo faz. Os nomes utilizados devem ser pronunciáveis, algo que você entenda. Observe no exemplo da Listagem 2 como essa prática torna o código mais fácil de ser entendido.
56
Engenharia de Software Magazine - Boas práticas de programação
Classes e métodos Nome de classes devem ser substantivos e não conter verbos. Já nomes de métodos devem conter verbos, pois eles indicam ações. A regra para métodos é: “A primeira regra dos métodos é que eles devem ser pequenos. A segunda regra é que eles devem ser menores ainda.” Métodos e classes menores são mais fáceis de ler e entender, além de manter é claro. Segundo o livro, podemos considerar as seguintes métricas: • Métodos <= 20 linhas; • Linha <= 100 caracteres; • Classe = 200 a 500 linhas.
Claro que toda regra tem sua exceção. Se você tem uma classe que vai precisar de mais linhas, um método que também precise de mais linhas, isso não é um problema. “Métodos e funções devem fazer somente uma coisa, fazê-la certa e somente fazê-la”.
DESENVOLVIMENTO
Poderíamos analisar essa frase como um princípio da coesão no seu código. Muitas vezes não é fácil saber se aquele método está fazendo somente uma coisa. Uma dica para isso é: você deve tentar extrair parte do seu código para um método, se você conseguir é porque aquele seu método realmente não está tendo uma função apenas. Imagine que você tenha um método onde quiséssemos mostrar os detalhes de um usuário:
com vários comentários que não serviam para nada e, pior, confundiam. Se um método ou uma classe estiver bem escrito, a importância do comentário é minimizada. Listagem 5. Métodos com objetivos mal definidos
public boolean verificarSenha(String senha){ if(senha.equals(“zzz”)){ Session.initialize(); return true; } return false; }
private void mostrarDadosUsuario(Usuario usuario){
mostrarCabecalhoUsuario(); System.out .print(“Nome: “, usuario.get Nome()); System.out .print(“Sobrenome: “, usuario.getSobrenome());
Listagem 6. Ajuste do objetivo do método
} if(verificaSenha(“zzz”){ Session.initialize(); }
Neste exemplo, as linhas do System.out.print são os detalhes do usuário. Mas será que isso não ficaria melhor escrito se estivesse de acordo com o código da Listagem 4?
public boolean verificarSenha(String senha){ if(senha.equals(“zzz”)){ return true; } return false; }
Listagem 4. Separando métodos
private void mostrarDadosUsuario(Usuario usuario){ mostrarCabecalhoUsuario(); mostrarDetalhesUsuario(); } private void mostrarDetalhesUsuario{ System.out.print(“Nome: “, usuario.getNome()); System.out.print(“Sobrenome: “, usuario.getSobrenome());
Outro ponto importante, um comentário não irá esconder um código ruim. Observe o exemplo a seguir: Date d1;
}
Esse código já está ruim, de nada adianta mudarmos para: Se um dia você quiser apenas listar os dados de um usuário ficará mais fácil. Agora temos os métodos separados. Essa prática também é um bom exemplo do tipo de refatoração chamada “Extract Method”. Um outro item que deve ser observado é a quantidade de parâmetros de um método. Você deve ter uma justificativa muito boa para ter uma quantidade tão grande de parâmetros em um método. Um agravante de um método com vários parâmetros é a dificuldade de se testar uma vez que você deverá testar todas as combinações possíveis. Outra situação a que você deve estar atento é com um método que informa que irá fazer uma determinada ação e faz outra. Observe a Listagem 5. O objetivo do método é verificar a senha, porém, se a senha estiver correta o mesmo inicia uma sessão, ou seja, o método já não tem a coesão esperada, pois possui duas responsabilidades. Uma solução melhor para esse cenário pode ser observada na Listagem 6.
Comentários nos códigos Comentários, apesar de importantes, podem trazer desinformação. Por que podemos afirmar isso? Alguém conhece programadores que atualizam comentários? Há vários códigos
Date d1; //dia da semana
Esse comentário não irá se propagar para todo o código e sempre que você se deparar com uma linha como “d1.after(d2);” você vai continuar não entendendo o propósito do código. Podemos tentar colocar uma regra nisso. Muitas vezes quando se comenta um código, pode ser que o mesmo precise ser refatorado. Lembra dos exemplos anteriores onde “d1” passou a ser “dataCompra”? Com essa mudança seu código pode ser entendido por todos e se fizermos essa refatoração o código passa a não precisar mais de comentário. Observe agora o exemplo a seguir: //Verifica se o usuário tem direito ao benefício if(usuario.getIdade() > 10 && usuario.getIdade() < 20){ …. }
Observe agora o exemplo ajustado na Listagem 7. Note que tiramos o comentário, melhoramos o código e o tornamos mais legível. Agora a leitura do código é sufic iente para saber o que ele realmente faz. Outro tipo de comentário que deve ser evitado é apresentado no exemplo a seguir: Edição 69 - Engenharia de Software Magazine
57
private boolean isUsuarioTemDireitoAoBeneficio(Usuario usuario){ if(usuario.getIdade() > 10 && usuario.getIdade() < 20){ return true; //Retorna verdadeiro } return false; //Retorna falso }
Listagem 7. Eliminando o comentário do código
if(isUsuarioTemDireitoAoBeneficio(usuario)){ …. } private boolean isUsuarioTemDireitoAoBeneficio(Usuario usuario){ if(usuario.getIdade() > 10 && usuario.getIdade() < 20){ return true; } return false; }
O return do método é lógico, não há necessidade de indicar o que o mesmo está retornando. Em relação a comentários, podemos dizer que: “Qualquer comentário que faça você olhar para outras partes do seu código para entendê-lo não valem os bits que consomem.”
Por outro lado, existem momentos em que o comentário é importante. Digamos que você tenha um trecho em seu
58
Engenharia de Software Magazine - Boas práticas de programação
código que vai demandar um tempo de proces samento alto ou a disponibilidade de um recurso. Nesses casos, comentários acabam sendo úteis. Algumas vezes também não se consegue colocar um nome em um método que explique o porquê o desenvolvedor tomou aquela decisão.
Formatação “Formatação é importante, pois se trata de comunicação.” Temos que considerar que o código é a maneira que a equipe de desenvolvimento vai se comunicar. Uma pessoa não gostaria de receber uma carta cifrada onde tivesse que interpretar o que está escrito nela, podemos pensar assim na hora de escrever um código. Outra ponto importante é que se você pega um código bem estruturado, você vai querer mantê-lo bem estruturado. É ruim para qualquer desenvolvedor ter acesso a um código sem formatação, sem endentação e ter que fazer sua leitura como se fosse um texto sem qualquer pontuação. Além disso, métodos com conceitos relacionados devem ficar verticalmente próximos e a ordem dos métodos deve criar um fluxo de leitura melhorando a legibilidade do código. Uma boa endentação é fundamental, mas não podemos ter muitos níveis. Observe como o trecho a seguir poderia se tornar confuso caso a lógica implementada fosse complexa:
DESENVOLVIMENTO
Os testes devem considerar as características F.I.R.S.T:
if(a>1){ if(b>1){ if(c>1){ if(z>1){
• *F (Fast): deve ser rápido. Testes demorados tiram a motivação
dos profissionais responsáveis por sua execução; …
} } }
• *I (Independent): não podem depender um do outro pois s e
um falha o outro vai falhar também; • *R (Reapetable): executando mais de uma vez eles devem
}
retornar sempre o mesmo resultado;
Tratamento de erros
• *S (Self-Validating): devem se autovalidar; • *T (Timely): devem ser feitos antes do código.
“Quando estamos programando devemos tratar os possíveis erros que nossa aplicação poderá lançar, as coisas podem dar errado e temos que estar certos que nosso código fará o que deve fazer.” Tratamento de erro é de responsabilidade do desenvolvedor. É preciso garantir que o código vai ter um tratamento para cada situação. Prefira lançar uma exception ao invés de retornar um código de erro. Estes retornos desorganizam a chamada do método e pode-se facilmente esquecer de verificá-los. Dentro do seu método você já pode ver o erro que está sendo retornado e tratá-lo ali. Defina o fluxo do método separando as regras de negócio de erros ou outras situações. Para seus erros, crie mensagens informativas mencionando a operação que falhou e o tipo de falha. Procure utilizar exceptions para situações inesperadas, por exemplo: seu código está lendo um arquivo e a rede se tornou indisponível.
TDD TDD nada mais é que o desenvolvimento guiado por testes. As três regras do TDD são: • Você não pode escrever um código até que tenha cr iado um
teste falhando; • Você não pode escrever mais teste do que seja suficiente
para falhar; • Você não pode escrever mais código do que o suficiente para
passar no teste que está falhando.
Refatoração Escrever um bom código muitas vezes pode não parecer uma missão tão simples. Considere o trecho de código a seguir: private boolean isStringVazia(String texto){ if (!StringUtils.isNullOrEmpty(texto) && !texto.equals(“”)) //... } }
{
Concorda que o “!texto.equals(“”)” não serve para nada? Se f izermos a refatoração a seguir obteremos o mesmo resultado: private boolean isStringVazia(String texto){ if (!StringUtils.isNullOrEmpty(texto)) { //... } }
Agora, digamos que ainda assim estivéssemos com receio de fazer essa refatoração. Neste caso, a presença de um simples teste unitário poderia eliminar a dúvida referente ao fato da funcionalidade continuar desempenhando seu papel corretamente. A refatoração é uma das melhores práticas para melhorarmos nosso código. Seu código pode ser eficaz, ou seja, fazer o que se deseja, mas também pode ser eficiente, fazer o que se deseja da melhor maneira possível.
Assim, se você tiver que testar se um CPF é válido, por exemplo, você deve criar alguns testes tais como:
Você gostou deste artigo?
• se o CPF for em branco; • se o CPF estiver com menos caracteres.
Dê seu voto em www.devmedia.com.br/esmag/feedback Ajude-nos a manter a qualidade da revista!
Edição 69 - Engenharia de Software Magazine
59