Aplicação de técnicas de gerenciamento de riscos em projetos de desenvolvimento de software: Estudo de Caso Sistema de Controle de Veículos

Transcrição

1 Aplicação de técnicas de gerenciamento de riscos em projetos de desenvolvimento de software: Estudo de Caso Sistema de Controle de Veículos Jair Ott (UNIPAR) Pablo A. Michel (UNIPAR) Agnaldo Izidoro de Souza (UNIPAR) Resumo: Por várias vezes foram constatados problemas e até fracassos com o desenvolvimento de software por não haver um controle minucioso sobre o projeto. Começase a codificar o programa sem se preocupar com planejamento, que se perde muito tempo e eleva o custo em elaborar o projeto para depois executá-lo, sendo pressionados por clientes que o software fique pronto o quanto antes e com um custo menor. Neste artigo será desenvolvida a pesquisa bibliográfica, abordando conceitos envolvidos em um projeto de desenvolvimento de software com ênfase no gerenciamento de riscos e técnicas que possam ser utilizadas para minimizar esses riscos que estão presentes em um projeto de desenvolvimento de software. Para a obtenção dos dados serão utilizados livros e artigos disponíveis na internet. Como resultados serão utilizados algumas técnicas de gerenciamento de riscos que serão aplicadas no estudo de caso do desenvolvimento de um Sistema de Controle de Veículos. À aplicação de técnicas no gerenciamento de risco em projetos de software através de estudo de caso foi atingida satisfatoriamente, onde foi possível identificar possíveis riscos que poderiam levar o projeto ao fracasso, mas que foram contornados a tempo através da aplicação das técnicas que serão mostradas nesse trabalho. Palavras-chave: Gerência; Risco; Importância. 1. Introdução A informação nos dias de hoje tem um valor altamente significativo e pode representar grande poder para quem a possui, com computadores e tecnologias gerando informações úteis, precisas, a um custo menor, em menos tempo, usando menos recursos e gerando riquezas. Uma empresa inserida na sociedade da informação deverá tirar total vantagem do uso de modernas tecnologias da informação para ganhar competitividade, onde demanda um alto nível de conhecimento focado para desenvolvimento de estratégias, planejamento de longo prazo e controles de gestão e de negócios. O trabalho de uma empresa depende de uma forma crescente do que os sistemas de informação são capazes de fazer, como o aumento da participação no mercado, a redução de custos e o desenvolvimento de novos produtos. Segundo Rezende e Abreu (2000) para obter um diferencial competitivo com base no processo acelerado de acúmulo de conhecimento, as empresas devem: automatizar as rotinas, motivar as pessoas a assumirem atividades que requerem criatividade e desenvolver autocapacitação nas empresas. As novas tecnologias vão sempre provocar mudanças no ambiente social da empresa, sendo difícil imaginar alguma inovação tecnológica que possa ser introduzida sem provocar algum efeito. Existe uma forte preocupação com a competitividade e o desempenho da concorrência, sem dizer as pressões dos clientes que também estão presentes. A tecnologia adquirida não garante todos os benefícios esperados, nem sequer que os investimentos feitos em sua aquisição tenham retorno. É preciso antes de tudo saber aproveitar as oportunidades que essas mudanças proporcionam, onde todo trabalho de análise, 1

2 programação e treinamento do usuário devem ser cuidadosamente conduzidos em todas as fases do projeto, pois esse trabalho, onde tanto esforço foi empregado, tanto pode dar certo como pode dar errado. Concordando com Sommerville (1996) e Pressman (1997) a área de engenharia de software tem produzido vários modelos de melhoria, processos, métodos e ferramentas para aumentar a probabilidade de que os projetos de software tenham sucesso, mas apesar de todos esses esforços, a literatura relata a falha nos projetos como algo comum. Os projetos de desenvolvimento de software lidam com um alto nível de incertezas, oriundas das mais diversas fontes, dentre elas, a mudança de tecnologia, a imaturidade nos processos, a adequação do perfil técnico para exercer uma atividade e a mudança contínua de requisitos. 2. Projeto Para Prado (2001) projeto é um esforço temporário, levado o efeito para criar um produto/serviço único. Já para PMBOK (2004) salienta que, o projeto é um empreendimento temporário com o objetivo de criar um produto ou serviço único. Vieira (2003) cita que, projeto é um empreendimento não repetitivo, com início, meio e fim, sendo conduzido por pessoas dentro de parâmetros predefinidos de tempo, custo, recursos envolvidos e qualidade. Concordando com Prado (2001) e Leopoldino (2004), todo projeto possui um ciclo de vida, o primeiro afirma que, durante o ciclo de vida, o projeto passa por diversas fases ou etapas e o conhecimento das características de cada uma delas é fundamental para seu sucesso, onde se podem destacar quatro fases genéricas: conceituação, desenvolvimento, execução e finalização. Já segundo PMBOK (2004) afirma que, o ciclo de vida de um projeto independe da área em que seja conduzido, baseando-se em etapas mais ou menos delineadas: definição, planejamento, execução, controle e finalização por conclusão ou cancelamento. Portanto, todas as fases do ciclo de vida do projeto é de suma importância planejar e controlar, e a gerência de projeto têm um papel fundamental para planejar a sua execução antes de iniciá-lo e acompanhar a sua execução, pois não havendo o planejamento e o controle de cada etapa pode ocorrer problemas que poderão ser irreversíveis. 3. Gerência de Projetos Na definição do PMBOK (2004), gerenciamento de projetos é a aplicação de conhecimentos, habilidades e técnicas para projetar atividades que visem a atingir ou exceder as necessidades e expectativas das partes envolvidas (stakeholders), com relação ao projeto. Este mesmo autor identifica nove áreas de conhecimentos que estão organizadas das seguintes maneiras: Gestão de Escopo, do Tempo, da Qualidade, de Recursos Humanos, de Contratos e Suprimentos (aquisição), de Custos, da Comunicação, de Riscos e da Integração. Concordando com Cleand e Ireland (2002) e Bruzzi (2002) quando afirmam que, mesmo com toda esta metodologia, não significa que não haverá riscos em um projeto, pois pode se tornar real ou não, dependendo da condução do mesmo. Mesmo aplicando todas essas metodologias no projeto, existem vários softwares que auxiliam no gerenciamento dos mesmos. Não serão feitas comparações de funcionalidades entre os aplicativos, pois o objetivo é apenas exemplificar a existência de tais produtos que muito auxiliam e agregam valor ao projeto. 2

3 O Task Tracking é um software nacional, desenvolvido pelo Laboratório de Tecnologia da Informação de Uberlândia/MG. Uma correta avaliação da produtividade permite aperfeiçoar o cronograma, alocando recursos corretos para cada tarefa, que pode ser avaliada em partes. A suíte do Task Tracking é composta por três módulos: TTCliente, TTAdministrador e TTOff-line, que podem auxiliar o gerente de projetos concentrando-se nos recursos: TTCliente: este é o módulo no qual as tarefas definidas pelo gerente de projetos são apresentadas aos recursos, permitindo assim aos recursos trabalharem nas tarefas e atualizá-las em tempo real. TTAdministrador: este é o módulo no qual o gerente de projetos pode manipular os usuários do sistema e suas permissões, visualizar o log das operações efetuadas. TTOff-line: esse módulo possui as mesmas funcionalidades que o TTCliente, mas trabalha de um forma totalmente independente do repositório. O recurso pode utilizar o TTCliente para gerar um arquivo de trabalho que será usado pelo TTOff-line, ou seja, pode-se trabalhar fora da sede da organização. O Microsoft Project 2002 inclui vários recursos e algumas melhorias muito significativas: Os recursos do Microsoft Project 2002 tornaram-se mais intuitivos; Os dados sobre projetos estão mais acessíveis, facilitando a colaboração entre os integrantes de equipes de projetos; As empresas podem utilizar uma plataforma de gerenciamento de projetos corporativos. Planejamento intuitivo: guia de instruções orienta o usuário, como organizar, gerenciar as tarefas e recursos, acompanhar o projeto; Integração total: importa listas de tarefas criadas no Microsoft Excel diretamente para o Microsoft Project; Facilidade de uso: com o auxílio de novos assistentes, pode-se simplificar o processo de configuração e acompanhamento de cronogramas de projetos. Melhor apresentação das informações: tenha uma visão mais abrangente de seus projetos, com os displays de agrupamento e apresentação das informações. O sucesso do projeto está baseado em oportunidades e em benefícios que tratam o valor do produto a ser entregue e em riscos que tratam das incertezas de se obter o produto dentro do custo, tempo, esforço e qualidade estimados. A disciplina que faz com que se prospere em circunstâncias de grandes incertezas é chamada de gerência de risco. Segundo Heldman (2005) quando for aplicada a gerência de risco em alguma instância, as possíveis conseqüências são todas aceitáveis, podendo haver convivência com o pior resultado esperado, sendo que o processo inicia com preocupações, dúvidas e desconhecimentos que se transformam em riscos aceitáveis. Com isto pode-se concluir, juntamente com Philips (2003), que a gestão de risco citada em PMBOK (2004) é fundamental para a execução do projeto, com o monitoramento constante das variáveis potenciais, pode-se empregar o gerenciamento de risco para isolar o impacto a ser causado pela mudança e/ou determinar modos de minimizar ou amenizar esses impactos. 3

4 5. Gerenciamento de Risco Segundo Prado (2001) pode-se conceituar gerenciamento de risco como uma quantificação das conseqüências que poderão ocorrer caso o projeto atrase ou ultrapasse o orçamento ou que possa ter problemas técnicos. Concordando com Vargas (2002) e Belloquim (2006) que com o gerenciamento de riscos possibilita a chance de melhor compreender a natureza do projeto, identificar os potenciais riscos do projeto e responder aos mesmos, geralmente associados a tempo, qualidade e custos. Os métodos de análise de risco empregados procuram verificar diversas fontes de risco, tais como: riscos provenientes de fornecedores, riscos provenientes de fatores externos, da disponibilidade de recursos e do grau de comprometimento da alta administração. Segundo Rezende e Abreu (2000) uma das maiores ameaças ao sucesso dos projetos de tecnologia em informação diz respeito as falhas de comunicação como, por exemplo a falta de envolvimento do usuário em todas as etapas ou fases do projeto, a falta de apoio dos altos executivos e levantamento de requisitos inconsistentes. Por isso recomenda-se que nenhuma ação seja tomada sem antes comunicar o fato ao usuário e sem documentar e ter seu aval, mesmo nas alterações de definições e/ou mudanças no escopo. Portanto, toda mudança, mesmo que para melhor, é sempre acompanhada de inconvenientes e desconfortos, que se precisa controlar. Concordando com Philips (2003) e Heldman (2005) quando afirmam que é conveniente compreender esses elementos que influenciam ou geram mudanças e como a alteração proposta pode afetar o projeto, se implementada e que pode exigir alterações no plano e no cronograma do projeto Controle de Mudanças Para Vieira (2004) o controle de mudanças é um processo interno que pode ser utilizado para impedir que qualquer pessoa, inclusive a gerência, altere o projeto sem justificativa apropriada. Exige-se que o solicitante tenha um bom motivo para que, em seguida, as mudanças propostas possam ser avaliadas em relação ao seu impacto sobre todos os lados do projeto. Segundo Philips (2003) muitas vezes o que ocorre é que a mudança é fundamental ao escopo do produto, e o gerente de projeto procura encaixar o plano do projeto nas novas e complexas exigências. Para evitar tal situação, é preciso que haja um controle da mudança e a sua implementação seja feita quando necessário. Quando as mudanças forem inevitáveis, será necessário um processo formal para incorporá-las no plano do projeto, conforme a tabela 4 da seção 5.3 onde diz respeito as técnicas. A mudança proposta se comprovada ter algum mérito, o gerente de projeto precisa pesquisar a mudança para determinar seu impacto sobre o projeto. Para auxiliar no diagnóstico, o gerente de projeto pode utilizar-se de algumas questões a seguir: Algum aspecto da solicitação de mudança requer recursos adicionais? (em caso positivo, que aspectos?); Algum aspecto da solicitação de mudança requer fundos adicionais? (em caso positivo, que aspecto?); Algum aspecto da solicitação de mudança requer tempo adicional? (em caso positivo, que aspecto?). Que áreas da solicitação de mudança têm mais impacto sobre o projeto? 4

5 Segundo Vieira (2006) uma reunião para gerenciamento de problemas permite que se trate dessas questões com a equipe, com o fornecedor ou com o pessoal-chave em busca de soluções. São técnicas que permitem que coloque o projeto de volta no caminho certo de forma rápida e precisa. Portanto para controlar as mudanças que deverão ser feitas, existem quatro estágios e que seus efeitos podem por em risco qualquer organização: rejeição, boicote, aceitação, cooperação. É preciso que o usuário seja estimulado a todo o momento a prosseguir com as mudanças, e que seja acompanhado até não mais pareçam que foram feitas às mudanças e sim um cotidiano. Concordam Cruz (2000) e Philips (2003) que as mudanças no projeto, mesmo que pareçam pequenas à primeira vista, são sempre mudanças importantes. O gerente de projetos deve ser firme e exigir da gerência, dos clientes e da equipe de projeto que permaneçam concentrados na visão original. Para auxiliar no gerenciamento de risco e na mudança no projeto, a PMBOK que é um subconjunto do abrangente conjunto de conhecimentos em gerenciamento de projetos possui vários processos que podem minimizar os riscos envolvidos em um projeto de desenvolvimento de software Gerência de risco no PMBOK O PMI Project Management Institute é uma instituição internacional sem fins lucrativos tendo sido criada com o objetivo de profissionalizar a área de gerenciamento de projetos, tem definido como prática essencial da gerência de projetos a execução do processo de gerência de riscos. A gerência de risco tem como objetivo maximizar os resultados de ocorrências positivas e minimizar as conseqüências de ocorrências negativas, através dos seguintes processos: planejar a gerência de risco, identificar riscos, analisar riscos qualitativamente, analisar riscos quantitativamente, planejar as respostas aos riscos, controlar e monitorar riscos, que serão vistos nas próximas subseções Planejar a Gerência de Risco Este processo tem a finalidade de definir a estratégia do gerenciamento de risco, os recursos necessários para a realização do processo e, por fim, a efetivação das ações consideradas necessárias no plano de gerência de risco, sendo terminado já no início do planejamento do projeto, pois ele é essencial para executar com sucesso os outros processos Identificar Riscos Segundo Machado (2002) o processo de identificação dos riscos visa identificar todos os riscos capazes de afetar o projeto e documentá-los. Segundo Mulcahy (2005) visa inclusive identificar as suas características, processo este iterativo, passando por constantes renovações, podendo envolver integrantes da equipe, stakeholders, usuários e quem mais puder ser afetado pelo projeto. Entretanto, é necessário identificar todos os eventos de risco e suas respectivas conseqüências. Existem várias possibilidades de riscos como orçamentos, cronogramas, mudanças no escopo, problemas técnicos, problemas com pessoal, hardware, riscos de âmbito jurídico. As técnicas constituem maneiras de ajudar a identificar os riscos do projeto. É importante 5

6 detectar todos os riscos tão logo quanto possível; quanto mais eficiente for o trabalho de identificação de riscos na etapa de planejamento, melhor será o plano de resposta a eles Analisar Riscos Qualitativamente Esse processo visa à detecção do impacto dos riscos identificados no projeto e sua probabilidade de ocorrência, classificando-os por prioridade, de acordo com os efeitos sobre os objetivos do projeto. Durante o ciclo de vida do projeto, deve ser reexaminada para acompanhar as mudanças nos risco do mesmo, levando em consideração no desenvolvimento de um plano de resposta aos riscos o cálculo da probabilidade de ocorrência de um risco, a avaliação de suas conseqüências e a correção das distorções do plano do projeto Analisar Riscos Quantitativamente Essa atividade avalia e quantifica a exposição do projeto aos riscos por meio da atribuição de probabilidades numéricas a cada um deles e aos seus impactos, determinando assim a probabilidade de atingir e quantificar a exposição dos riscos e o tamanho das reservas de contingência de custos e prazos do projeto. Após o planejamento de respostas a riscos e também como parte do monitoramento e controle de riscos, é necessário ser repetida para determinar se o risco total do projeto diminuiu de forma satisfatória Planejar as Respostas aos Riscos São processos que especificam as medidas a serem tomadas para reduzir ameaças e tirar proveito das oportunidades encontradas nos processos de análise de riscos. Quanto mais eficazes os planos de respostas aos riscos, maiores as chances de êxito no projeto; quando bem desenvolvidos e bem escritos, esses planos reduzem os riscos globais do projeto, onde são usadas várias estratégias neste processo para reduzir ou controlar o risco, sendo que a tabela 1 é um exemplo. É importante escolher a estratégia certa para cada risco, de modo que o risco e seus impactos sejam tratados de forma eficaz. Após determinar a estratégia a ser empregada, deve-se desenvolver um plano de ação para levá-la a cabo se o evento de risco se concretizar. Deve-se estabelecer também uma estratégia secundária ou de reserva. Em todos os projetos existem riscos, e o planejamento contra eles é uma parte importante do processo de planejamento do projeto. O simples ato de identificar os riscos e planejar respostas pode diminuir seu impacto, caso eles se confirmem Controlar Riscos e Monitorar Riscos A atividade de controlar e monitorar riscos envolve a avaliação da situação atual para determinação de possíveis desvios do plano inicial de gerência de risco. A atividade de controle dos riscos avalia a situação corrente para determinar eventuais desvios do planejado. O controle dos riscos envolve a alteração das estratégias de mitigação, quando se fizer necessário, na utilização de ações previamente planejadas de contingência. Segundo Mulcahy (2005) esta etapa envolve controlar o projeto de acordo com o planejamento da resposta do 6

7 risco e pode incluir as seguintes atividades: mantendo-se a par dos riscos identificados, implementação das respostas do risco, verificar os riscos quando acontecerem, monitorando os riscos, identificar novos riscos, assegurar a execução do planejamento do risco, avaliar a eficácia do plano dos riscos, desenvolverem novas respostas a novos riscos Técnicas Nessa seção serão apresentadas algumas técnicas que poderão auxiliar como base para o gerenciamento dos riscos que podem afetar futuramente o projeto. São tabelas retiradas de obras literárias dando a credibilidade e a confiabilidade de que se conduzidas de forma correta poderão identificar, estabelecendo assim como será tratado o risco se porventura acontecer. Na tabela 1, fornece um exemplo de técnica de como podemos identificar e o que deve ser feito quando o risco identificado acontecer, ou seja, o objetivo é estabelecer as contramedidas para eliminar os riscos levantados. TABELA 1 - Plano de ação para contramedidas PLANO DE AÇÃO PARA CONTRAMEDIDAS Fonte de risco Contramedida Responsável Data limite Fonte: Bruzzi (2002). A tabela 2 fornece alguns exemplos com o objetivo de facilitar o preenchimento do quadro de riscos, onde aquelas perguntas para as quais as respostas forem "não" devem ser analisadas em profundidade. TABELA 2 - Exemplo de quadro de riscos Item de Risco Sim Não 1 Estruturação do Projeto É possível prever exatamente quais as necessidades deste projeto? Este projeto envolve um único departamento da empresa? 2 Tecnologia do Projeto A tecnologia a ser utilizada neste projeto é do perfeito conhecimento da equipe executora? 3 Comprometimento da Alta Administração do Cliente para com este projeto A alta administração do cliente sabe exatamente o que este projeto produzirá? A alta administração do cliente conhece os benefícios deste projeto para a empresa? 4 Interface com este projeto Existem projetos correndo em paralelo e cujos resultados podem afetar este projeto? Fonte: Prado (2001). 7

8 Um outro questionário de riscos pode ser utilizado para identificar as maiores fontes de riscos. A tabela 3 fornece alguns exemplos de perguntas do questionário. TABELA 3 - Questionário de riscos Perguntas Qual é o tempo estimado para o projeto? ( ) um ano ou menos ( ) 13 meses até dois anos ( ) mais de dois anos Número de departamentos envolvidos? ( ) um ( ) dois ( ) três ou mais Hardware ou software adicionais são necessários para o projeto? ( ) nenhum ( ) mudança de processador ( ) periféricos ( ) novos computadores ( ) mudança de plataforma Fonte: Vieira (2003) Peso Baixo = 1 Médio = 2 Alto = 3 Baixo = 1 Médio = 2 Alto = 3 Baixo = 1 Médio = 2 Médio = 3 Alto = 4 Alto = 5 A tabela 4 é um exemplo de formulário para controle das solicitações de mudanças se porventura as mesmas forem inevitáveis e que o gerente de projetos deverá pesquisar e analisar se é viável esse pedido ou não. TABELA 4 - Formulário de solicitação de mudança do projeto Formulário de solicitação de mudança do projeto Nome do projeto Seu nome e informações de contato Data: Resumo da mudança desejada Motivo para a mudança desejada Fonte: Philips (2003) O solicitante precisa descrever a mudança e explicar o motivo pelo qual deseja a mudança. Depois o gerente de projeto tem como verificar se a mudança realmente é necessária, se deve ser rejeitada ou adiada até a conclusão do projeto. 6. Estudo de Caso A técnica adotada para a condução do estudo de caso foi a de entrevistas com os stakeholders. Através do estudo de caso serão aplicados os conceitos de projeto, de gerenciamento de projeto e de risco, como também software para o gerenciamento dos mesmos e de técnicas para minimizar os riscos aqui estudados. O estudo de caso consiste em desenvolver um sistema de controle de veículos de uma empresa de ônibus, onde a mesma controla os dados relevantes dos seus veículos como placa, chassi, multas tanto da esfera municipal, estadual e federal como também multas aplicadas pelo Ministério dos Transportes, as respectivas defesas entre outros, através de planilhas. 8

9 O sistema proposto é que sejam interligados esses dados evitando assim redundâncias e que forneça a informação desejada. Para que o sistema fosse desenvolvido fez-se necessário que se aplicassem os conceitos, software e técnicas para o bom andamento do trabalho, controlando assim o projeto do início até o fim, controle esse focado no gerenciamento de risco Metodologia Primeiramente, foi explicado como seriam conduzidos os trabalhos, os resultados obtidos através da pesquisa de campo e o formulário a ser preenchido durante a entrevista. Como observação, vale ressaltar que foi colocado para os gerentes que seria normal que mudanças, pois algum tratamento dos fatores de risco era esperado, tanto em termos de prevenção como de contingência, e que novos fatores poderiam surgir. Para atingir aos objetivos estabelecidos foram realizadas entrevistas para a coleta de dados que consistiam no preenchimento das tabelas 1, 2 e 3, sendo recolhidos dados de gerentes, usuários e desenvolvedor e definição de datas para cada etapa e custo do projeto. O instrumento de coleta dos dados foi inicialmente concebido em três etapas, contendo a caracterização da amostra, onde foram recolhidos dados sobre a empresa, as estimativas de gravidade e de ocorrência dos riscos. Para o acompanhamento e controle do projeto utilizou-se o software MSProject 2002, para controlar o tempo e o custo, como também as etapas a serem executadas no projeto. Após a fase inicial foi elaborada a lista de riscos a ser utilizada conforme a tabela 1. Foram identificados vários riscos entre elas: a falta de comprometimento da alta gerência com o projeto, sendo que a contramedida é reunir-se para discutir e cobrar o que foi acordado na reunião. Também foi identificada a falta de envolvimento adequado do usuário e a falta de cooperação dos usuários. Nesse caso, primeiramente, haveria uma reunião com as partes para verificar o que estava acontecendo e, não resolvendo, a gerência seria comunicada. O prazo de execução de tarefas mal estimadas ou requisitos mal entendidos também foi citado e em contramedida ficou estabelecido que primeiramente se averiguasse o que estaria acontecendo através de relatórios periódicos que o MSProject 2002 emite e depois reunir-se-ia para a busca da solução. Com a lista elaborada, seguiu-se a sua validação, ou seja, todos concordaram sobre o que estava escrito. Então, após a aplicação da tabela 1, aplicou-se juntamente com os envolvidos no projeto as tabelas 2 e 3 para somente o preenchimento das questões já formuladas Resultados Obtidos A aplicação de técnicas no gerenciamento de risco em projetos de software através de estudo de caso foi atingida satisfatoriamente. Foram identificados riscos mais relevantes em termos de probabilidade, impacto e da união das duas variáveis. Durante o andamento do projeto houve vários problemas que foram identificados no início do projeto e que pôde ser contornado, mesmo com a identificação do risco o prazo foi comprometido, em contrapartida o custo e qualidade não foram afetados. Se tais riscos não tivessem sido identificados, poderia levar o projeto a problemas irreversíveis, ou seja, ao fracasso. No entanto, não foi estimado que o projeto tivesse de ser paralisado, devido a questões financeiras que a empresa estava atravessando. Os stakeholders decidiram que o 9

10 projeto teria de ser cancelado, mas através de estudos foi demonstrado que o projeto não precisaria ser cancelado e sim adiado temporariamente, não se perdendo todo o trabalho até aqui desenvolvido e nem toda a documentação feita até então. Mudanças como essa em que o projeto deve ser cancelado ou paralisado por problemas financeiros não foge da realidade do mundo dos negócios em que se vive hoje. Portanto quando ocorrer um fato dessa natureza, cabe ao gerente de projetos negociar juntamente com os envolvidos no projeto realizando pesquisa da viabilidade do não cancelamento. Ao retornarem os trabalhos houve a necessidade de adequar o cronograma e o custo do projeto para se ter a real situação do mesmo, aumentando significativamente o custo e o tempo da conclusão das atividades, e constatou-se a importância dessa documentação no ato do reinicio do projeto. A não documentação de todas as etapas do projeto feitas anteriormente a paralisação do projeto, ninguém saberia ao certo o que fazer primeiro, ou por onde começar. Mesmo assim alguns profissionais na área de tecnologia de informação e de clientes não acreditarem serem necessários ter um controle do projeto e dos riscos envolvido no mesmo, dizendo que quando acontecerem irão resolvê-los, que é perda de tempo e aumenta muito o custo para documentar e controlar o projeto. As principais contribuições desta pesquisa foi constatar a importância de se implementar a gerência de risco nos projetos de desenvolvimento de software e o levantamento de componentes de risco que podem ser utilizados pelos gerentes de projetos nas suas atividades de gerência de riscos, levando-se em conta a gravidade e a ocorrência dos riscos como fatores distintos. 7. Conclusão Primeiramente é importante ressaltar que o tempo demandado para a execução do processo de identificação e quantificação não é muito longo, pois o estudo de caso levou em torno de 2 horas para preenchimento e discussão do projeto, e 1 hora de explanação sobre o trabalho que seria realizado. O enfoque desta pesquisa foi de apresentar técnicas e ferramentas eficientes e eficazes para o desenvolvimento de software, ligado à metodologia de gestão de risco. Pode-se afirmar que as tendências atuais da gestão de projetos proporcionam às empresas maior confiabilidade nos produtos que estão sendo desenvolvidos, estabelecendo assim uma seqüência de processos, evitando assim desperdícios, retrabalhos e evitar jornadas de trabalho exaustivas. Ficou também evidenciado que a implementação da gestão de risco em projetos de desenvolvimento de software exige investimento em soluções de tecnologia e na formação de recursos, pois desenvolver um sistema não é apenas inserir linhas de comandos. Este artigo confirma a importância da gerência de risco para a seleção e controle de projetos de software com o objetivo de que as organizações passem a tratar riscos de uma maneira menos intuitiva em seus projetos de software. Pode-se observar que a ligação dos procedimentos práticos baseados em processos teóricos que envolvem profissionais e tecnologias, possibilitam automatizar e centralizar os processos e documentações inerentes ao desenvolvimento de sistemas. Também se pôde comprovar que a gerência de risco é uma disciplina onde se deve considerar não somente processo, pessoa e tecnologia, que fazem parte do desenvolvimento do software, mas também aspectos administrativos da empresa, como por exemplo, a influência política da organização e do cliente no projeto. 8. Referências 10

11 BELLOQUIM, A. Riscos de Projetos: que fazer com eles?. Disponível em < Acesso em: 23 mar (reportagem disponível em meio eletrônico). BRUZZI, D. G. Gerência de projetos: uma visao pratica. Sao Paulo: Erica, (obra, livro, folheto, trabalho acadêmico com único autor). CLEAND, D. I.; IRELAND, L. R. Gerência de projetos. Rio de Janeiro: Reichmann & Affonso, (obra, livro, folheto, trabalho acadêmico com dois autores). CRUZ, T. Sistemas de informações gerenciais: tecnologias da informação e a empresa do século XXI. São Paulo: Editora Atlas, (obra, livro, folheto, trabalho acadêmico com único autor). HELDMAN, K. Gerência de projetos: guia para o exame oficial do PMI. Rio de Janeiro: Elsevier, (obra, livro, folheto, trabalho acadêmico com único autor). LEOPOLDINO, C. B. Avaliação de riscos em desenvolvimento de software Dissertação (Mestrado de Administração) Universidade Federal do Rio Grande do Sul, Rio Grande do Sul. Disponível em: < Acesso em: 01 mar (Dissertação, Mestrado, trabalho acadêmico disponível em meio eletrônico). MACHADO, C. A. F. A-Risk: Um método para identificar e quantificar risco de prazo em projetos de desenvolvimento de software Dissertação (Mestrado em Ciências) Pontifícia Universidade Católica do Paraná, Paraná. Disponível em: < Acesso em: 13 mar (Dissertação, Mestrado, trabalho acadêmico disponível em meio eletrônico). MULCAHY, R. PMP Exam Prep: Accelerated Learning to Pass PMI s PMP Exam. 5º ed. RMC Publications, Inc., (obra, livro, folheto, trabalho acadêmico com único autor). PHILIPS, J. Gerência de projetos de tecnologia da informação. Rio de Janeiro: Campus, (obra, livro, folheto, trabalho acadêmico com único autor). PMBOK. Conjunto de Conhecimentos em Gerenciamento de Projetos. 3º ed. Global Standard. Campus Boulevnad. Newtown Square, (obra, livro, folheto, trabalho acadêmico com único autor). PRADO, D. S. Planejamento e controle de projetos. Belo Horizonte: Editora de Desenvolvimento Gerencial, (obra, livro, folheto, trabalho acadêmico com único autor). PRESSMAN, R. S. Software engineering: a practitioner's approach. New York: McGraw-Hill, (obra, livro, folheto, trabalho acadêmico com único autor). REZENDE, D. A.; ABREU, A. F. Tecnologia da informação aplicada a sistemas de informação empresariais. São Paulo: Editora Atlas, (obra, livro, folheto, trabalho acadêmico com dois autores). SOMMERVILLE, I. Software Engineering. New York: Addison-Wesley, (obra, livro, folheto, trabalho acadêmico com único autor). VARGAS, R. V. Gerenciamento de projetos: estabelecendo diferenciais competitivos. Rio de Janeiro: Brasport, (obra, livro, folheto, trabalho acadêmico com único autor). VIEIRA, E. N. O. Gerenciando projetos na era de grandes mudanças: uma breve abordagem do panorama atual Disponível em < Acesso em: 03 abr (trabalho acadêmico disponível em meio eletrônico). VIEIRA, M. Gerenciamento de projetos de tecnologia da informação. Rio de Janeiro: Elsevier, (obra, livro, folheto, trabalho acadêmico com único autor). VIEIRA, R. W. D. D. Gerenciando Mudanças. Disponível em < gestaodeprojetos/2003/03/19/2003_03_19_0004.2xt/-template_interna>. Acesso em: 03 mai (reportagem disponível em meio eletrônico). 11