UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU PROJETO A VEZ DO MESTRE

UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU PROJETO A VEZ DO MESTRE GERENCIAMENTO DE RISCOS NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Por: Teresa Maria Julieta Costa Orientador Prof. Luiz Claudio Lopes Alves D. Sc Rio de Janeiro 2010

2 UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU PROJETO A VEZ DO MESTRE GERENCIAMENTO DE RISCOS NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Apresentação de monografia à Universidade Candido Mendes como requisito parcial para obtenção do grau de especialista em Gestão de projetos Por:. Teresa Maria Julieta Costa.

3 AGRADECIMENTOS...aos meus amigos, familiares, colegas de trabalho e as pessoas que de uma forma ou de outra me ajudaram nesta pesquisa...

4 DEDICATÓRIA...dedico ao meu companheiro, Carlos Eduardo que me incentivou e me deu força para a conclusão de mais esta etapa...

5 RESUMO Atualmente muitas organizações, envolvidas com o desenvolvimento de software, se voltam para o Gerenciamento de Riscos como forma de antecipar e minimizar o efeito de eventos que possam impactar negativamente nos objetivos dos projetos de TI da empresa. O objetivo desta monografia é apresentar um modelo de gerenciamento de risco contendo um conjunto de informações sobre riscos nas fases de desenvolvimento do software, começando pela fase de levantamento de requisitos até a implantação em produção, além de conceituar algumas ferramentas de gerenciamento de riscos existente no mercado para registrar os riscos, seus impactos e controles das fases e das atividades do projeto, mantendo assim uma base de dados histórica de riscos que auxilia a resolução de problemas semelhantes.

6 METODOLOGIA A pesquisa colheu informações em livros, revistas acadêmicas e especializadas, artigos e teses nas áreas de gerenciamento de riscos e metodologias de desenvolvimento de software. Primeiramente a monografia apresenta uma revisão dos conceitos e técnicas de desenvolvimento de software de TI e de gerenciamento de riscos. De acordo com Thomsett (2002), os projetos de desenvolvimento de software têm basicamente duas vertentes uma técnica e outra gerencial. O autor afirma que, por determinado período, muita atenção foi dada ao aprimoramento dos modelos de desenvolvimentos de software (ênfase técnica), ficando o componente gerencial relegado ao segundo plano. Depois analisa os riscos inerentes em cada fase de desenvolvimento do software e em seguida descreve algumas ferramentas de gestão de riscos.

7 SUMÁRIO INTRODUÇÃO... 9 CAPÍTULO I... GERENCIAMENTO DE RISCO... 11 1.1 - Modelos de Gerenciamento de Risco... 12 1.2 - Gerência de Risco segundo o PMBOK (PMI, 2004)... 15 1.3 - Gerência de Risco segundo Software Engineering Institute (SEI) 19 CAPÍTULO II... METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE... 25 2.1 - Modelo Cascata... 26 2.2 - Modelo Incremental... 27 2.3 - Modelo Espiral... 28 2.4 - Modelo de Prototipagem... 29 CAPÍTULO III... RISCOS NAS FASES E ATIVIDADES NOS PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE... 30 3.1 - Classe de Riscos... 30 3.2 - Riscos associados nas fases de desenvolvimentos de software.. 31 3.2.1 - Proposta - Aspectos comerciais... 31 3.2.1.1 - Análise dos Custos Iniciais de Levantamento... 32 3.2.1.2 - Avaliação e Definição do Escopo... 32 3.2.1.3 - Preparação da Proposta... 34 3.2.1.4 - Evolução dos Negócios... 34 3.2.2 - Engenharia de Requisitos... 35 3.2.2.1 - Entendimento do Empreendimento do Cliente... 36 3.2.2.2 - Extração e Análise de Requisitos com a Técnica de Entrevistas... 36 3.2.2.3 - Especificação e Documentação dos Levantamentos... 37 3.2.2.4 - Validação do Usuário... 38 3.2.2.5 - Cálculo de Prazos... 39 3.2.2.6 - Prototipagem... 40 3.2.2.7 - Acompanhamento do Usuário... 40 3.2.3 - Projetos... 41 3.2.3.1 - Especificação Técnica... 42 3.2.3.2 - Especificação de Programa... 43 3.2.3.3 - Elaboração de Planos de Testes... 43 3.2.3.4 - Especificação de Casos de Testes... 44 3.2.4 - Desenvolvimento... 45 3.2.4.1 - Desenvolvimento dos Programas... 45 3.2.4.2 - Testes de Unidade... 47 3.2.4.3 - Acompanhamento do Usuário... 48 3.2.5 - Testes... 48 3.2.5.1 - Testes de Integração... 49 3.2.5.2 - Testes de Validação/Funcionalidades... 50 3.2.5.3 - Testes de Sistemas... 51

3.2.5.4 - Avaliação e Liberação para o Usuário... 52 3.2.5.5 - Ajustes e Acertos Gerais... 53 3.2.6 - Instalação e Liberação... 53 3.2.6.1 - Instalação dos Equipamentos de Produção... 54 3.2.6.2 - Avaliação Final e Aceite do Produto... 55 3.2.6.3 - Finalização dos Manuais de Usuários e Técnicos... 55 3.2.6.4 - Treinamento... 56 3.2.7 - Operação... 57 3.2.7.1 - Atendimento Help-desk... 57 3.2.7.2 - Administração da Base de Dados... 58 3.2.7.3 - Administração dos Hardwares e Softwares utilizados no uso do Sistema... 58 3.2.8 - Manutenção... 59 CAPÍTULO IV... FERRAMENTAS DE GERENCIAMENTO DE RISCOS... 61 4.1 - Módulo Risk Manager... 61 4.2 - Regence... 63 CONCLUSÃO... 66 BIBLIOGRAFIA... 67 FOLHA DE AVALIAÇÃO... 69 8

9 INTRODUÇÃO A presença do risco é inerente a qualquer projeto, e seus efeitos podem ser bastante variados, desde nenhum impacto até um completo desvio dos objetivos planejados. Todo projeto envolve incertezas, que podem estar associadas a diversos fatores, tais como a perda de pessoas importantes da equipe de projeto, o uso de novas tecnologias, alterações inesperadas na legislação, flutuações de mercado, mudanças organizacionais, entre outros. Os eventos de risco há muito tempo têm sido reconhecidos e considerados pelos gerentes de projeto, mas o tratamento aplicado a eles normalmente se resume à adoção de margens de segurança para determinadas áreas do projeto (escopo, cronograma, custos e etc). Essa abordagem, no entanto, se revelou insuficiente para garantir o sucesso de projetos, sobretudo daqueles que apresentam maior porte e complexidade. Para aumentar as chances de sucesso e assegurar um grau satisfatório de alcance dos objetivos de um projeto, o gerenciamento de risco tem-se tornado ferramenta essencial para os gerentes de projeto, devendo estar presente em todo o ciclo de vida de um empreendimento. Os projetos relacionados à tecnologia da informação (TI), nesse contexto, se diferenciam de outros projetos por apresentarem características próprias de complexidade, tais como a dificuldade de visualização clara do produto que está sendo desenvolvido, a necessidade de envolvimento e participação dos usuários, a precisão das definições dos requisitos, a resistência a mudanças e a escolha da tecnologia a ser utilizada. Esses aspectos indicam a presença de riscos peculiares ao universo da tecnologia da informação, que já colaboraram para diversos casos de insucesso em projetos dessa área, desde sistemas implantados com atraso ou a um alto custo, até sistemas cujas funcionalidades não atendiam às reais necessidades de seus usuários, tornando-se desnecessários.

10 A utilização efetiva do gerenciamento de risco é, portanto, um dos fatores chave para se alcançar uma conclusão satisfatória de um projeto. O gerenciamento de risco visa estabelecer uma política que defina meios e recursos para identificar, qualificar, quantificar, desenvolver um plano de ações e controlar eventos que podem causar impactos indesejáveis no curso ou resultado do projeto. Sem as devidas ferramentas para o gerenciamento adequado desses projetos e de seus riscos, aumentam-se as probabilidades de conclusão insatisfatória, provocando perdas financeiras significativas, decorrentes do consumo inadequado de tempo, dinheiro, recursos materiais e humanos. Estudos evidenciam a necessidade do uso adequado das metodologias de gerenciamento de risco, que ajudam as pessoas a evitar desastres, retrabalhos e cancelamento de projetos, além de estimular uma situação de sucesso nos projetos (MACHADO, 2002). O objetivo desta monografia é apresentar um conjunto de informações sobre os riscos, divididos em classes de riscos, inerente a cada fase do ciclo de vida de desenvolvimento de software. O Capítulo I apresenta os principais fundamentos teóricos de Gerenciamento de Riscos. O Capítulo II comenta sobre as Metodologias de Desenvolvimento de Sistemas. Nesta monografia descreverá os modelos de desenvolvimento em Cascata, Espiral, Incremental e de Prototipagem O Capítulo III detalha para cada fase e atividade dos processos de desenvolvimento de software os riscos conhecidos. Esses riscos são agrupados por classe de riscos. O Capítulo IV apresenta algumas ferramentas de gerenciamento de riscos. Finalizando com a conclusão da monografia e a bibliografia.

11 CAPÍTULO I GERENCIAMENTO DE RISCO Risco é a possibilidade de acontecer alguma coisa ruim, um problema. Gerenciamento é a ação de administrar um determinado processo. Portanto, Gerenciamento de Risco é o ato de administrar as possíveis causas dos problemas que poderão ocorrer. Gerenciamento de risco é um processo da engenharia de software com métodos e ferramentas para administrar riscos em um projeto. Isto fornece um ambiente disciplinado para tomadas de decisões com informações de quantidades de riscos que podem ocorrer, determinação sobre quais riscos são importantes e que devem ser tratados, além de informações relacionadas ao desenvolvimento de estratégias para lidar com risco. Baseado em Sherer (1995), Risco de Software é a perda esperada que pode ocorrer no desenvolvimento, na utilização ou na manutenção do software. Com a evolução tecnológica, os riscos de hardware foram minimizados, ficando o software como a maior fonte de problemas que podem resultar em perdas financeiras substanciais. Além de que os softwares estão em constante evolução e manutenção. Risco, por si só, não é ruim. Risco é essencial para a evolução do projeto, e falha é freqüentemente uma parte chave de aprendizagem, mas é necessário aprender a avaliar as conseqüências negativas associadas aos riscos. Todo projeto apresenta algum nível de risco associado ao produto em desenvolvimento ou manutenção. Riscos podem aparecer em áreas como: alteração do pessoal de desenvolvimento, mudanças de condições de mercado e de expectativas do cliente e mudanças de condições de negócio. Quanto mais cedo se compreende o risco, o Gerenciamento de Risco nos projetos será mais bem efetuado.

12 1.1 - Modelos de Gerenciamento de Risco São modelos aplicáveis a projetos de todas as áreas do conhecimento e adotados por várias organizações. Dentre eles, destacam-se o modelo proposto pelo PMI (2004) e o modelo proposto por Chapman e Ward (1997). Segundo a abordagem do PMI (2004), o gerenciamento de risco é um processo sistemático de identificar, analisar e responder aos riscos do projeto. Este processo visa tanto maximizar a probabilidade e o impacto de eventos positivos, como minimizar a probabilidade e o impacto de eventos negativos aos objetivos do projeto. O PMI considera o risco como um evento ou condição incerta, que, uma vez ocorrido, provoca um impacto positivo (oportunidade) ou negativo (ameaça). De acordo com essa visão, o gerenciamento de riscos deve ser desenvolvido por meio das seguintes etapas: planejamento do gerenciamento de risco, identificação dos riscos, análise qualitativa de riscos, análise quantitativa de riscos, planejamento de respostas a riscos, controle e monitoração de riscos. Chapman e Ward (1997) estabelecem que o propósito essencial do gerenciamento de risco é melhorar o desempenho do projeto, por meio de uma sistemática de identificação, avaliação e tratamento de riscos relacionados a projeto. Por isso, propõem um modelo formal para gerenciamento de risco em projetos, caracterizado por um ciclo composto pelos seguintes processos: definir (consolidação de todas as informações relevantes sobre o projeto), enfocar (elaboração de um plano estratégico para o gerenciamento de riscos), identificar riscos, estruturar (teste das premissas sobre risco), atribuir propriedade (definição das pessoas responsáveis pelo gerenciamento dos riscos e respostas, com suas respectivas responsabilidades), estimar (probabilidades e impactos), avaliar (síntese e validação das estimativas), planejar (o que será feito com os riscos) e gerenciar (monitoramento, controle e replanejamento). São modelos para gerenciamento de risco em projetos que foram concebidos e desenvolvidos para a área de TI. Destacam-se nesta categoria, o

13 modelo proposto pelo Software Engineering Institute (SEI), o método PRINCE2 e o modelo proposto pela Microsoft. O conceito enfatizado pelo SEI é o de gerenciamento contínuo de risco (Continuous Risk Managament, CRM), definido como uma prática de engenharia de software com processos, métodos e ferramentas para gerenciamento de riscos em projetos, proporcionando um ambiente disciplinado para a tomada de decisão pró-ativa com relação aos seguintes aspectos: avaliação contínua de riscos, seleção dos riscos mais importantes e implementação de estratégias para lidar com os riscos selecionados. Para viabilizar o CRM, o SEI criou o paradigma do gerenciamento de risco, composto pelas seguintes funções: identificar os riscos, analisar os riscos, planejar as respostas aos riscos, monitorar os indicadores dos riscos e, finalmente, controlar os planos desenvolvidos para aperfeiçoamento do processo. A função comunicar é responsável pela integração das demais funções (SEI, 2003). O método PRINCE2 (Projects in Controlled Environment, versão 2) foi introduzido em 1989 pela Agência Central de Computação e Telecomunicações (Central Computer and Telecommunications Agency, CCTA), que hoje faz parte do Escritório Comercial de Governo (Office of Government Commerce, OGC), tendo se tornado um padrão para gerenciamento de projetos públicos e privados no Reino Unido (OGC, 2003). O gerenciamento de risco é um dos componentes do método, sendo definido como um processo contínuo, estruturado e pró-ativo para reduzir a chance de exposição a eventos futuros que podem trazer conseqüências negativas para o projeto, impedindo o alcance de seus objetivos. As fases desse processo são: identificação de riscos, estimativa de risco (priorizar os riscos em função de sua probabilidade, impacto e horizonte temporal), avaliação de riscos (decidir se o risco é aceitável ou não, e determinar as ações para torná-lo aceitável) e implementação das ações (OGC, 2003). Em 1994 a Microsoft criou uma metodologia de gerenciamento de projetos denominada Microsoft Solutions Framework (MSF), que tem como uma de suas disciplinas o gerenciamento de riscos, com base no CRM do SEI.

14 O processo é cíclico e composto por seis passos lógicos: identificar os riscos, analisá-los e priorizá-los, planejar e agendar as ações, monitorar os riscos e relatar sua situação, controlar os riscos para execução de planos de contingência e, por último, aprender e registrar as lições decorrentes do processo (MICROSOFT, 2002). A literatura existente sobre o assunto tem caráter conceitual, como convém a modelos de gerenciamento, carecendo de detalhes e resultados de implementações específicas. Check lists são freqüentemente citados para verificação de riscos, mas, no conhecimento dos autores, a única ferramenta existente para levantamento consistente de riscos na área de projetos de TI é o TBR (Taxonomy Based Risk), desenvolvido pela SEI (1993). Mesmo nesse caso, o TBR é um roteiro de identificação sistemática de riscos associados ao desenvolvimento de projetos de software. Roteiros da mesma natureza para riscos em outros tipos de projeto não foram encontrados na literatura. Durante a década de 90, as organizações internacionais de normatização mostraram crescente preocupação com o gerenciamento de risco, o que fica evidenciado pela evolução do tratamento dado ao assunto nas normas publicadas recentemente, como a ISO/IEC 10006 Diretrizes para a qualidade em gerenciamento de projetos (ISO, 2000), a ISO/IEC 12207 - Tecnologia da informação Processos de ciclo de vida dos softwares, e sua revisão (ISO, 1995 e 2002), a ISO/IEC Guide 73 Gerenciamento de riscos Vocabulário Diretrizes para uso em padrões (ISO, 2002) e a ISO/IEC 17666 Sistemas espaciais Gerenciamento de risco (ISO, 2003). Um dos benefícios da normatização é a padronização de termos e definições relacionados ao gerenciamento de risco, possibilitando um entendimento comum aos diversos públicos. Além disso, as normas trazem também conceitos, princípios, processos e tarefas pertencentes ao universo do gerenciamento de risco. Nesta monografia será abordado a Gerência de Riscos segundo Project Management Institute (PMI) e Software Engineering Institute (SEI).

15 1.2 - Gerência de Risco segundo o PMBOK (PMI, 2004) Segundo o PMBOK (PMI, 2004), a gerência de risco inclui os seguintes processos: Planejamento do gerenciamento de riscos, Identificação de riscos, Análise qualitativa de riscos, Análise quantitativa de riscos, Planejamento de respostas a riscos e Monitoramento e controle de riscos. Planejamento do gerenciamento de riscos Um planejamento cuidadoso e explícito aumenta a possibilidade de sucesso dos outros cinco processos de gerenciamento de riscos. O planejamento do gerenciamento de riscos é o processo de decidir como abordar e executar as atividades de gerenciamento de riscos de um projeto. O planejamento dos processos de gerenciamento de riscos é importante para garantir que o nível, tipo e visibilidade do gerenciamento de riscos estejam de acordo com o risco e a importância do projeto em relação à organização, para fornecer tempo e recursos suficientes para as atividades de gerenciamento de riscos e para estabelecer uma base acordada de avaliação de riscos. O processo Planejamento do gerenciamento de riscos deve ser terminado já no início do planejamento do projeto. Identificação de riscos determinação dos riscos que podem afetar o projeto e documentação de suas características. É um processo iterativo porque novos riscos podem ser conhecidos conforme o projeto se desenvolve durante todo o seu ciclo de vida. Normalmente conduz ao processo Análise qualitativa de riscos. Alternativamente, também pode conduzir diretamente ao processo Análise quantitativa de riscos quando realizado por um gerente de riscos experiente. Em alguns casos, a simples identificação de um risco pode sugerir sua resposta e esses casos devem ser registrados para análise e implementação adicionais no processo Planejamento de respostas a riscos. Análise qualitativa de riscos A análise qualitativa de riscos avalia a prioridade dos riscos identificados usando a probabilidade deles

16 ocorrerem, o impacto correspondente nos objetivos do projeto se os riscos realmente ocorrerem, além de outros fatores, como o prazo e tolerância a risco das restrições de custo, cronograma, escopo e qualidade do projeto. A análise qualitativa de riscos é normalmente uma maneira rápida e econômica de estabelecer prioridades para o planejamento de respostas a riscos, e estabelece a base para a análise quantitativa de riscos, se esta for necessária. Análise quantitativa de riscos A análise quantitativa de riscos é realizada nos riscos que foram priorizados pelo processo Análise qualitativa de riscos por afetarem potencial e significativamente as demandas conflitantes do projeto. O processo Análise quantitativa de riscos analisa o efeito desses eventos de risco e atribui uma classificação numérica a esses riscos. Ela também apresenta uma abordagem quantitativa para a tomada de decisões na presença da incerteza. Este processo usa técnicas como a simulação de Monte Carlo e a análise da árvore de decisão para: o Quantificar os possíveis resultados do projeto e suas probabilidades o Avaliar a probabilidade de atingir objetivos específicos do projeto o Identificar os riscos que exigem mais atenção quantificando sua contribuição relativa para o risco total do projeto. o Identificar metas realistas e alcançáveis de custo, cronograma ou escopo, quando fornecidos os riscos do projeto o Determinar a melhor decisão de gerenciamento de projetos quando algumas condições ou resultados forem incertos. Planejamento de respostas a riscos é o processo de desenvolver opções e determinar ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto. Ele vem após os processos Análise qualitativa de riscos e Análise

17 quantitativa de riscos. Inclui a identificação e designação de uma ou mais pessoas (o(s) proprietário(s) das respostas a riscos ) que irão assumir a responsabilidade sobre cada resposta a riscos acordada e financiada. O planejamento de respostas a riscos aborda os riscos de acordo com a sua prioridade, inserindo recursos e atividades no orçamento, cronograma e plano de gerenciamento do projeto, conforme necessário. As respostas a riscos planejadas precisam ser adequadas à importância do risco, econômicas ao enfrentar o desafio, rápidas, realistas dentro do contexto do projeto, acordadas por todas as partes envolvidas, e ser de propriedade de uma pessoa específica. É freqüentemente necessário selecionar a melhor resposta a riscos a partir de diversas opções. O Planejamento de respostas a riscos apresenta abordagens comumente usadas para planejar respostas aos riscos. Os riscos incluem as ameaças e oportunidades que podem afetar o sucesso do projeto e são discutidas respostas para cada uma delas. Monitoramento e controle de riscos é o processo de identificação, análise e planejamento dos riscos recém-surgidos, acompanhamento dos riscos identificados e dos que estão na lista de observação, reanálise dos riscos existentes, monitoramento das condições de acionamento de planos de contingência, monitoramento dos riscos residuais e revisão da execução de respostas a riscos enquanto avalia sua eficácia. O processo Monitoramento e Controle de riscos aplicam técnicas, como análise das tendências e da variação, que exigem o uso dos dados de desempenho gerados durante a execução do projeto. O monitoramento e controle de riscos, e também os outros processos de gerenciamento de riscos, constituem um processo contínuo em toda a vida do projeto. Outros objetivos do monitoramento e controle de riscos são determinar se: o As premissas do projeto continuam válidas

18 o O risco, conforme avaliado, mudou seu estado anterior, usando a análise das tendências o Os procedimentos e políticas de gerenciamento de riscos adequados estão sendo seguidos o As reservas para contingências dos custos ou do cronograma devem ser modificadas de acordo com os riscos do projeto. Esses processos interagem entre si e também com processos de outras áreas de conhecimento. Cada processo pode envolver o esforço de uma ou mais pessoas ou grupos de pessoas, com base nas necessidades do projeto. Cada processo ocorre pelo menos uma vez em todos os projetos e também em uma ou mais fases do projeto, se ele estiver dividido em fases. Embora os processos estejam apresentados como elementos distintos com interfaces bem definidas, na prática eles podem se sobrepor e interagir de várias maneiras.

19 Figura 1.1: Processos de Gerenciamento de Riscos PMBOK. (PMI, 2004) 1.3 - Gerência de Risco segundo Software Engineering Institute (SEI) O relatório técnico da SEI, elaborado por Willians e outros (1999), apresenta sete princípios que fornecem uma estrutura para gerenciamento efetivo de risco. Os princípios são: Perspectiva global. Visualiza o desenvolvimento de software no contexto da definição de sistemas em um nível maior que o desenvolvimento do projeto. Reconhece o valor potencial de oportunidade e o provável impacto de efeitos adversos.

20 Visão futurista. Pensa no amanhã, identifica incertezas, antecipa potenciais resultados. Administra recursos e atividades de projeto enquanto antecipa incertezas. Comunicações abertas. Encoraja a comunicação das informações entre todos os níveis de projeto. Habilita comunicação informal e formal. Usa processos de valorização ao indivíduo, traz conhecimento e visão única para identificar e gerenciar risco. Gerenciamento integrado. Faz do gerenciamento de risco uma parte vital e integrada da administração de projeto, adaptando métodos de gerenciamento de risco e ferramentas à infra-estrutura e à cultura de um projeto. Processo contínuo. Sustenta vigilância constante. Identifica e gerencia rotineiramente os riscos através de todas as fases do ciclo de vida do projeto. Compartilhamento da visão do produto. Visão única do produto baseada em um propósito comum, compartilhando a comunicação coletiva e com enfoque em resultados. Equipe de trabalho. Trabalhando cooperativamente para alcançar uma meta comum. É um conjunto de talentos, habilidades, e conhecimento. Os princípios especificados acima são importantes para o gerenciamento de risco, pois evidenciam a necessidade de se estabelecer uma linha mestra para identificação de riscos em projetos de software e a necessidade de criar e desenvolver um processo contínuo de gerenciamento efetivo de risco. Além disso, determina a abrangência total desse gerenciamento nas etapas de desenvolvimento de software. A SEI, também, enfatiza o aspecto contínuo do gerenciamento de risco. Daí o nome Gerenciamento de Risco Contínuo (CRM). Quando o Gerenciamento de Risco Contínuo é utilizado, os riscos são identificados continuamente em todas as fases do projeto. Os riscos

21 identificados são analisados, ou são resolvidos, ou eles se transformam em problemas e são tratados como tais. Em alguns projetos, os riscos são verificados uma única vez durante o planejamento inicial do projeto onde os maiores riscos são identificados e minimizados, mas dessa forma os riscos nunca são totalmente identificados. O Gerenciamento de Risco envolve um processo sistemático e contínuo que pode ser mais bem entendido pelo paradigma representado na Figura 1.2. Os elementos do paradigma de gerenciamento de risco, ilustrado na Figura 1.2, são descritos a seguir. As atividades são seqüenciais, porém devem ocorrer continuamente, ou seja, enquanto alguns riscos são monitorados outros e novos riscos são identificados durante o processo de desenvolvimento de software. Figura 1.2: Paradigma de Gerenciamento de Risco. (SEI, 2003) Identificar. Os riscos do projeto devem ser identificados e conhecidos antes que se tornem problemas. Analisar. Transforma os riscos em dados, para tomada de decisão, durante o desenvolvimento do projeto. Planejar. Planejar e incluir ações para resolver ou minimizar riscos do presente e do futuro.

22 Acompanhar. Monitorar as indicações de riscos e acompanhar as ações de minimização. Controlar. Corrigir os defeitos do planejamento de minimizar os riscos. Comunicação. Habilitar e compartilhar toda a informação do projeto. O método da SEI para avaliação de risco é o SRE Software Risk Evaluation Avaliação de Riscos de Software, descrito no relatório técnico de Willians e outros (1999), e se divide em cinco fases: Contratação, Identificação e Análise de Riscos, Relatório Intermediário dos Riscos Identificados, Plano Estratégico de Minimização dos Riscos e o Relatório Final dos Riscos com informações do plano estratégico e controles. As etapas do método de implantação da avaliação de riscos de software são apresentadas resumidas: Contratação. A fase Contratação consiste das atividades de identificar as necessidades e objetivos do projeto. Determina os recursos para o seu desenvolvimento. Identificação e análise do risco. Nessa fase, a equipe do projeto de Avaliação de Risco de Software conduz entrevistas com a equipe do projeto e com os usuários para identificar os Riscos. Os riscos são analisados e priorizados considerando o impacto no projeto e agrupados dentro das áreas de risco. Os itens referentes às incertezas, experiências anteriores, preocupações e questões a resolver serão úteis na identificação dos riscos. Várias fontes podem ser utilizadas nesta fase, tais como: o Pessoas: clientes, integrantes da equipe, organizações envolvidas, disponibilidade, capacidade, experiência, etc. o Produto e Processo: abrangem requisitos, prazos, estimativas, receitas, despesas, orçamento, restrições de natureza legal, estilo de gerenciamento, tamanho e escopo do projeto, etc.

23 o Tecnologia: inclui mudanças, inovação, adoção e uso, integração e interfaces, experiência específica, segurança, arquitetura, distribuição na escala, etc. Relatório intermediário. Nesta fase os riscos são relacionados por área, com uma recomendação para que na próxima fase seja efetuado o plano estratégico para sua solução ou minimização de impacto no projeto. Planejamento da estratégia de minimização. O Planejamento da Estratégia de Minimização é a fase que seleciona as áreas de riscos com maior impacto para o projeto. A equipe do projeto e da avaliação do risco trabalha em conjunto para determinar metas, estratégias e atividades que vão minimizar os assuntos identificados dentro das áreas de risco. Relatório final. As informações dos planos de estratégia da minimização de riscos e as ações tomadas são mostradas no relatório final e apresentadas ao gerente do projeto. Figura 1.3: Etapas do processo de avaliação de risco segundo SEI.. (Willians e outros, 1999)

24 Os principais benefícios da avaliação dos riscos de software no processo de desenvolvimento de softwares conforme SEI (1993), são: Obtém uma visão compartilhada de riscos do projeto para que toda a equipe possa conhecê-los. Produz uma estrutura comum para falar sobre os riscos e como minimizá-los. Fornece a habilidade para a identificação e a minimização do risco sistematicamente com orientações de cálculo de exposição do risco, identificação de prioridades. Fornece motivação para melhorar o nível do projeto. Produz informação para tomada de decisão do gerente do projeto.

25 CAPÍTULO II METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE Um dos fatores que mais tem influenciado a mudança de vida das pessoas é a produção de software. Software está atualmente, especialmente com o advento da Internet, em todos os locais e atividades da sociedade: hospitais, empresas, controle de tráfego aéreo, educação e etc. Há muito tempo, o software deixou de apenas automatizar as tarefas realizadas pelas pessoas para também mudar a forma destas realizações. Nos anos 60 e 70 a produção de software se dava de forma desorganizada e sem nenhuma sistematização. Isto gerou uma grande insatisfação por parte dos consumidores, ou clientes, dos softwares produzidos. Esta insatisfação surgiu em decorrência de atrasos em cronogramas, orçamentos estourados e da baixa qualidade do produto final. Todos estes problemas ficaram conhecidos mundialmente como a Crise do Software. A Engenharia de Software surgiu para tratar das teorias, métodos e ferramentas relacionadas à produção de software. Tudo isto almejando maior qualidade, custo e prazo previsíveis para o produto gerado. A partir de então, produzir software é mais do que programar é também documentar, produzir modelos, realizar tarefas. Surgem os conceitos como ciclos de vida de desenvolvimento e metodologias. No processo de desenvolvimento de software, se utiliza uma metodologia conhecida por Ciclo de Vida de Software (CVS). Peters e Pedrycz (2001) definem CVS como sendo o período de tempo que se inicia com o conceito de um produto de software e acaba sempre quando o software é disponibilizado para utilização. Refere-se ao período de tempo durante o qual a sua existência tem significado, desde o surgimento da idéia inicial para a realização do software até a retirada de utilização.

26 O Modelo de Ciclo de Vida de Software (MCVS) representa as atividades, entradas e saídas, documentos, tabelas, medições e suas interações durante o CVS. Alguns modelos de Ciclo de Vida de Software são apresentados: Modelo Cascata Modelo Espiral Modelo Incremental Modelo de Prototipagem 2.1 - Modelo Cascata Também conhecido como Linear Sequencial. Nesse ciclo de vida, assumes que as atividades de análise, projeto e implementação podem ser feitas de forma seqüencial, sem que sejam necessárias interações entre as fases. Um ciclo de vida em cascata típico tem as seguintes fases: 1. Modelagem do Sistema, onde são estabelecidos os requisitos do sistema do qual o software sendo realizado participa, incluindo os requisitos de informação e de negócios. 2. Análise de Requisitos, onde são modeladas os requisitos de informação, funcionais, comportamentais, de desempenho e de interface do software.. 3. Projeto, onde são planejadas as estruturas de dados, a arquitetura do sistema e o comportamento é mapeado em procedimentos. 4. Codificação, onde o projeto é transformado em uma linguagem inteligível pelo computador 5. Testes, onde verificamos e validamos o software 6. Manutenção, onde garantimos a utilizabilidade do software Esse Ciclo de Vida, defendido inicialmente como a forma correta de desenvolver software. Devido a divisão radical entre as fases, é dada grande ênfase a documentação. Inicialmente assumia-se que cada fase seria executada por

27 uma equipe distinta de especialistas. Também havia discussões sobre até que ponto deveria ir o projeto e onde começava codificação. De acordo com a complexidade do sistema, muitas vezes as fases de codificação e testes eram dividas em codificação e teste de unidades e integração e testes de integração. Entre os principais problemas desse ciclo de vida está no fato que o cliente só vê o produto final no último dia do desenvolvimento. Assim, é impossível detectar falhas ou atender demandas imediatas do cliente. Além disso, a participação do usuário é muito baixa. Figura 2.1: Ciclo de Vida em Cascata. (Pressman, 2002) 2.2 - Modelo Incremental O modelo incremental é semelhante ao modelo Cascata. Os requisitos e os conceitos do software são as primeiras atividades a serem desenvolvidas e identificadas. Em seguida, as demais atividades do desenvolvimento do software são repetidas cada vez que há uma nova versão do software. Baseiase no conceito de que requisitos de software permanecem estáveis e tendem a evoluir devido às mudanças na tecnologia e na experiência. Pode ser visto como combinando o linear com a prototipagem. Tem o foco principal na entrega do produto. Para realizá-lo, repetimos a seqüência linear em vários calendários defasados no tempo. Busca implementar funcionalidades essenciais o mais cedo possível.

28 Figura 2.2: Ciclo de Vida Incremental. (Pressman, 2002) 2.3 - Modelo Espiral O modelo Espiral foi desenvolvido por Barry Boehm em 1988 e abrange as melhores características do modelo em Cascata acrescido de uma nova atividade que é a análise de Risco. O Ciclo de Vida Espiral se caracteriza pelo desenvolvimento por uma série de produtos desenvolvidos em seqüência, cada vez mais complexos e mais próximos do produto final desejado. Ele se diferencia do ciclo de vida incremental porque os produtos de cada ciclo não são sub-sistemas do sistema original, mas sim produtos específicos que atendem necessidades específicas do projeto, como por exemplo teste de viabilidade e definição da interface com o usuário. Em cada ciclo da espiral, algumas atividades são realizadas em ordem seqüêncial: comunicação com o cliente, planejamento, análise de riscos, engenharia, construção e, finalmente, avaliação dos resultados. Figura 2.3: Ciclo de Vida em Espiral. (Pressman, 2002)

29 2.4 - Modelo de Prototipagem No Ciclo de Vida de Prototipagem (pura) o desenvolvedor interage diretamente com o usuário, escutando seus pedidos e desenvolvendo, imediatamente, um protótipo do produto desejado. O usuário então utiliza esse protótipo e fornece ao desenvolvedor novas informações que o levam a modificar o protótipo, de maneira a atender todas as necessidades do usuário. É claramente um processo de desenvolvimento baseado em um ciclo de realimentação de informações, com alta participação do usuário. Não existe uma fase formal de análise ou projeto. Isso pode causar problemas graves e difíceis de corrigir no produto final, dificultando de sobremaneira a manutenção dos produtos. Pouca ênfase é dada a documentação. Atualmente quase todos os ciclos de vida utilizam protótipos, mas não um ciclo de vida de prototipagem. Existem vários tipos de ciclo de vida com prototipagem. Usamos protótipos descartáveis quando o protótipo é usado apenas para levantar alguns ou todos os requisitos e depois abandonado, em troca de uma implementação mais organizada. Um protótipo operacional é um software feito rapidamente para atender uma demanda do usuário e que é usado, mais tarde, como modelo de especificação para uma nova implementação do sistema. Figura 2.4: Ciclo de Vida de Prototipagem. (Pressman, 2002)