Home

Monografia final - Portal do Conhecimento

1. Contrato cliente fornecedor 74 1 Insuficiente 2 Suficiente 3 Bom 4 Muito bom Costuma utilizar algum s modelo s formal s de desenvolvimento de software orientado a objectos an lise estruturada etc Sim E N o E Qual quais Que coment rio tem a acrescentar sobre riscos e dificuldades no desenvolvimento de projectos de software em Cabo Verde Obrigado pela sua colabora o
2. A caracter stica mais importante do planeamento precisamente a listagem daquilo que n o sabemos porque o que precisamos descobrir precisamente o que n o sabemos Por isso h que ter capacidade para reconhecer riscos e de conseguir tra ar estrat gias para os minimizar ou mesmo combate los Nesta fase n o temos que ter respostas para todos os problemas mas sim saber que eles existem e planear a forma de os atacar mais tarde 5 3 2 A dificuldade de medi o As pessoas que dizem como um trabalho deve ser feito n o s o as mesmas que executam o trabalho De facto os l deres precisam de alguma forma de medir o qu o efectivo s o os trabalhadores Isto particularmente relevante para software devido dificuldade de aplicar medi es Mesmo com nossos melhores esfor os somos incapazes de medir at mesmo as coisas mais simples a respeito de software como por exemplo produtividade Introduzir gest o por medidas sem boas medidas leva aos seus pr prios problemas Problemas esses que impedem a equipa de conseguir alcan ar os seus objectivos quanto qualidade do software em constru o 5 4 PROCESSO DE DESENVOLVIMENTO 5 4 1 Especifica es de requisitos As especifica es de requisitos s o um trabalho imprevis vel ou seja est o sempre a mudar Esta uma realidade que n o pode surpreender a ningu m Isto porque podemos considerar que mudan as de requisitos de neg cio ao construir software consti
3. 5 2 M TODOS DE GEST O 5 2 1 Experi ncia do Chefe de Projecto Segundo Miguel 2002 p 13 o chefe de projecto deve orientar se para o cliente e deve possuir a necess ria autoridade para poder operar eficazmente nesta ptica que o chefe de projecto deve ter as seguintes caracter sticas para atacar com profissionalismo as diversas dificuldades inerentes a um projecto de software e Possuir uma profunda compreens o dos objectivos do projecto e Sercapaz de compreender as necessidades do seu pessoal e Ter uma boa reflex o sobre os detalhes e Estar fortemente comprometido com o projecto e Ser capaz de lidar com desaires e desilus es 45 e Possuir boas aptid es de negocia o na medida em que uma grande parte da vida do projecto gasta a tentar adquirir recursos e Ser pr tico e orientado para os resultados e Estar consciente dos custos e possuir aptid es de gest o b sicas e Ser politicamente sensato isto estar consciente daquilo que se deve ou n o fazer e Possuir uma elevada toler ncia ambiguidade Os projectos funcionam com base nas datas e or amentos fixos assim como especifica es cuidadosamente concebidas como parte dos objectivos fundamentais Independentemente das incertezas e dificuldades no desenvolvimento de software o chefe de projecto deve ser capaz de tra ar estrat gias para contrariar as for as que visem impedir que os objectivos sejam alcan ados Diversos problemas d
4. Modelo de processo de software uma descri o simplificada de um processo de software que apresentada a partir de uma perspectiva especif ca Os modelos pela sua natureza s o simplifica es e assim um modelo de processo de software uma abstrac o do processo real que est sendo descrito Engenharia de software uma disciplina da engenharia que se ocupa de todos os aspectos da produ o de software desde os est gios iniciais de especifica o do sistema at a manuten o desse sistema ap s ter entrado em opera o M todos s o meios organizados de produzir software Eles incluem sugest es sobre o processo a ser seguido as regras que regem as descri es de sistema produzidas e as directrizes do projecto Risco um contexto que inclui as amea as vulnerabilidade e o valor a proteger Gest o de risco um processo de tomada de decis es que implica a considera o de factores pol ticos sociais econ micos e de engenharia com a avalia o de risco relacionada a um perigo potencial a fim de desenvolver analisar e comparar op es de controle e escolher a melhor resposta para a seguran a ante esse perigo Bugs um erro involunt rio de programa o que pode n o ser respons vel pelo bloqueio de uma aplica o programa ou sistema operativo mas que causa alguns problemas na opera o ou utiliza o 63 2 An lise de Risco uma actividade que reflecte a preo
5. dizer que os modelos e as metodologias a serem adoptados poder o tamb m ser diferentes O objectivo de um modelo de processo de software proporcionar ao projecto uma estrutura que reduza a exposi o aos v rios tipos de riscos como ultrapassar o or amento produzir o sistema errado e que nunca funcione etc se mantenha a um n vel considerado aceit vel Ap s a an lise do estudo do caso que fizemos sobre o desenvolvimento de software em Cabo Verde constatamos que muitas das organiza es que desenvolvem software n o usam nenhum modelo formal Isto ocorre porque estes geralmente n o s o adequados s realidades das organiza es cabo verdianas As organiza es pequenas e m dias n o possuem recursos suficientes para adoptar o uso de processos pesados Esta falta de sistematiza o na produ o de software ter como resultado a baixa qualidade do produto al m de dificultar a entrega do software nos prazos e custos predefinidos e inviabilizar a futura evolu o do software A estrutura o e sistematiza o de um projecto de desenvolvimento de software s o indispens veis para a sua gest o De um projecto sem estrutura n o se pode fazer estimativas sobre o seu custo ou a sua qualidade n o se pode definir pontos cr ticos e o seu progresso n o pode ser monitorizado E por isso para evitar o fracasso de um projecto a estrutura o deve ser um dos pontos essenciais a ter em conta Isto se consegue com a utiliza
6. O Qualquer projecto implica risco O objectivo de um projecto estabelecer ou obter algo novo apostar e arriscar O risco inerente s actividades O que queremos saber o que podemos fazer para evitar as causas e as consequ ncias O desenvolvimento de software por si s arriscado mas n o problem tico desde que se tenha feito uma boa an lise de risco E para fazer uma boa an lise de risco h que responder estas quest es que s o relevantes no nosso entender para poder tomar uma posi o quanto a viabilidade do projecto de software Que riscos corremos Porqu Quais as consequ ncias Qual a sua gravidade O que podemos fazer para minimizar a exposi o ao risco Temos formas de controlo do risco Como Apesar do risco ser algo inerente aos projectos de desenvolvimento de software uma atitude comum face ao risco ignorar e esperar que nada de grave aconte a Contudo existem muitos projectos de software desastrosos que poderiam ter sido evitados caso tivesse sido realizada uma gest o de riscos desde a fase inicial do projecto nomeadamente na Gest o de Requisitos No entanto o desenvolvimento de software n o constitui o nico empreendimento humano arriscado Novos procedimentos m dicos novos edif cios novas medidas financeiras tamb m possuem riscos ou seja todos podem falhar O risco faz parte de qualquer actividade humana e n o pode ser nunca eliminado O risco em si n o mau o risco esse
7. O processo de gest o de riscos como todos os outros planeamentos de projecto devem funcionar de forma interactiva ao longo de todo o projecto O risco faz parte de qualquer actividade humana n o podendo ser eliminado na plenitude O risco em si n o mau essencial ao progresso e o insucesso constitui muitas vezes uma componente fundamental da aprendizagem Para tal devemos aprender a equilibrar as poss veis consequ ncias negativas do risco com os benef cios da respectiva oportunidade associada Ap s a realiza o do estudo do caso em Cabo Verde podemos concluir que os riscos mais frequentes no desenvolvimento de software em Cabo verde s o press o excessiva sobre os prazos inexperi ncia de utilizadores baixa produtividade e inexperi ncia do pessoal Quanto aos riscos mais perigosos temos estimativas inadequado de custos derrapagens or amentais baixa qualidade e fric o entre pessoal empresa cliente fornecedor Para al m desses riscos mais comuns e mais perigosos que as empresas de desenvolvimento de software est o sujeitas no nosso pa s ainda deparam com outros problemas nomeadamente 58 a falta de credibilidade nas capacidades t cnicas de gest o e planeamento Um outro problema prende se com a falta de recursos para adquirir as ferramentas actualizados fora do pa s para lhes ajudar no desenvolvimento de um produto de qualidade capaz de fazer face a concorr ncia dos softwares importados Isto faz
8. online 18 de Novembro de 2003 citado em 5 de Mar o de 2006 15 00 Dispon vel em http www sucesues org br documentos index asp cod noticia 349 DURSCKI Roberto SPINOLA Mauro BURNET Robert REINEHR Sheila Linhas de Produto de Software riscos e vantagens de sua Implanta o online 26 de Novembro 65 de 2004 citado em 11 de Janeiro de 2006 15 30 Dispon vel em http www dimap ufrn br andre gti 16 linha de producao pdf J nior Jos W da Silva Uma disciplina para a engenharia de software estudo do personal software process PSP proposto por Watts Humphey a proficionaliza o do desenvolvedor de software online Dezembro de 2004 citado em 5 de Mar o de 2006 15 00 Dispon vel em http www ufpel tche br prg sisbi bibct acervo info 2000 Mono Jose Wilson pdf LUIZ Ronaldo Rezende Vilela Obtendo qualidade de software com RUP online 6 de Dezembro de 2004 citado em 7 de Janeiro de 2006 11 00 Dispon vel em http www javafree org content view jf idContent 7 MATOS A Jos Dicion rio de Inform tica e Novas Tecnologias 2 edi o aumentada Lisboa FCA Editora de Inform tica 2004 MIGUEL Ant nio Gest o de Projectos de Software Lisboa FCA Editora de inform tica 2003 MIGUEL Ant nio Gest o do risco e da qualidade no desenvolvimento de software S ed Lisboa FCA Editora de inform tica 2002 O BRIEN james A Introducion to information syste
9. poss vel acontecer visto que seres humanos podem cometer erros Nesta situa o tempo dinheiro m o de obra etc foram desperdi ados O problema do modelo em Cascata sua inflex vel divis o do projecto em fases distintas o que dificulta poss veis altera es que s o comuns no desenvolvimento de um projecto E por isso esse modelo s deve ser utilizado somente quando os requisitos forem bem compreendidos O que quer dizer que o software tem de ser totalmente especificado antes do seu in cio visto que a altera o dos requisitos pode constituir um problema enorme devido a sequencialidade de tarefas Um outro ponto importante a ter em conta s o os requisitos e a sua caracter stica de volatilidade No modelo em cascata comum a pr tica de congelar os requisitos levantados antes de se iniciar a realiza o das demais fases do desenvolvimento Isto os requisitos considerados eram os mesmos do in cio ao fim do projecto de desenvolvimento Bezerra 2003 De facto a volatilidade dos requisitos um facto com o qual a equipe de desenvolvimento tem de conviver Sistemas grandes em complexidade podem levar meses ou at anos para serem desenvolvidos Na actualidade devido a grande concorr ncia entre as empresas dif cil pensar que o usu rio espere pacientemente at que o sistema todo esteja pronto para ser utilizado Mesmo que isto aconte a pode haver o risco de que o sistema j n o correspond
10. 70 x 800 000 560000 Durante a avalia o de risco h que examinar melhor as estimativas que foram feitas na previs o de risco ordenar os riscos que foram descobertos e come ar a pensar sobre modos de controlar e at mesmo evitar riscos que s o prov veis de ocorrer Na avalia o de risco h que realizar os seguintes passos 1 Definir os n veis de refer ncia de risco para o projecto 2 Tentar desenvolver uma rela o entre cada tripla risco probabilidade do risco impacto do risco e cada um dos n veis de refer ncia 3 Prever o conjunto de pontos de refer ncia que definem uma regi o de encerramento limitada por uma curva ou reas de incerteza 4 Tentar prever como combina es compostas de riscos afectar o um n vel de refer ncia e Refinamento de risco Ap s a identifica o de um risco este pode ser identificado de uma forma generalizadA Mas com o andar do tempo prosseguindo nos est gios de planeamento de risco o gerente vai obtendo informa es do projecto e do risco que lhe possa refinar o risco num conjunto de riscos mais detalhados O objectivo desse refinamento conseguir uma forma mais f cil de atenuar monitorar e administrar os riscos Retomando o exemplo da sec o 4 4 2 alinea d podemos escrever Considerando que os componentes de software reutiliz veis devem satisfazer padr es de projectos espec ficos e que alguns n o satisfazem ent o a preocupa o de que possivelmente ap
11. DE RISCOS O objectivo principal da informa o de risco providenciar o enquadramento para desenvolver a informa o de risco necess ria para ajudar no processo de decis o Durante o planeamento do futuro da empresa a administra o deve garantir que todos os cuidados foram tomados para que seus planos se concretizem A formaliza o de uma an lise de risco prov um documento que indica se este cuidado foi observado O resultado da an lise de risco d organiza o o controle sobre seu pr prio destino Atrav s do relat rio final pode se identificar quais controles devem ser implementados em curto m dio e longo prazo Como analisar riscos sem estudar minuciosamente os processos de neg cios que sustentam sua organiza o O que quero proteger Como classificar o risco destes processos sem antes avaliar as vulnerabilidades dos componentes de tecnologia relacionados a cada processo Quais s o os seus processos cr ticos Aqueles que sustentam a rea comercial a rea financeira ou a produ o Para cada pergunta uma mesma resposta conhecer para proteger Azevedo 2002 A transcri o acima demonstra claramente o objectivo da an lise de risco e reflecte a preocupa o que as empresas de desenvolvimento de software t m em saber qual o grau de exposi o frente s amea as capazes de comprometer os objectivos da sua opera o Isto torna a an lise de risco uma actividade imprescind vel 28 4 3 CA
12. MB B MB MB Muito Baixa MB 69 Quadro 4 Exemplo de tabela de risco antes da ordena o Riscos Categoria Probabilidade Pessoal inesperiente Tamanho e experi ncia 35 Cr tico da equipa Cliente modificar os Tamanho do produto Cr tico requisitos Prazo de entrega ser Impacto do neg cio Marginal apertado Tecnologia n o Tecnologia a ser usada Catastr fica satisfar as expectativas Quadro 5 Quadro de riscos ordenados Riso Probabilidade Impacto Problemas financeiros organizacionais for am redu es Baixa Catastr ficas no or amento do projecto imposs vel recrutar pessoal com as habilidades Alta Catastr ficas requeridos para o projecto Pessoas chave est o doentes em per odos cruciais do moderada S rios projecto Componentes de software que deviam ser reutilizadas Moderada S rios cont m defeitos que limitam sua funcionalidade O banco de dados utilizado no sistema n o pode processar moderada S rios tantas transac es por segundo como esperado As ferramentas CASE n o podem ser integradas Alta Toler veis Tamanho do software subestimado Alta Toler veis O c digo gerado pelas ferramentas CASE ineficiente Moderada Insignificantes 7 E i x E E f RMMM contem ponteiro para um plano de atenua o monitora o e administra o de risco ou seja para uma colec o de folhas de informa o de risco desenvolvida para todos os riscos que fica acima d
13. de planos Por estas raz es muito conveniente fazer agrupamento de riscos para poder fazer a mitiga o Isto principalmente quando se tem uma grande quantidade de riscos visto que s o mais facilmente mensur veis atrav s da sua classifica o em grupos relacionados Isto tudo faz com que os respons veis pela mitiga o desses grupos de riscos tenham conhecimento o suficiente sobre esses riscos por forma a estabelecer as suas rela es causas consequ ncias e os objectivos de mitigar o conjunto de riscos 4 4 4 Monitora o de riscos A monitora o de riscos consiste em avaliar constantemente os riscos e revisar os planos para a diminui o de riscos a medida que mais informa es sobre eles se tornam dispon veis S o avaliados regularmente cada um dos riscos identificados a fim de decidir se esse risco est se tornando mais ou menos prov vel bem como se os efeitos desses riscos se modificaram E claro que isso n o pode ser observado de modo directo Portanto devem ser examinados outros factores para serem levantados ind cios sobre a probabilidade e seus efeitos Esses factores como obvio s o dependentes do tipo de risco A monitora o de riscos deve ser um processo cont nuo durante todo o processo de desenvolvimento de software onde cada um dos riscos principais deve ser considerado separadamente e discutido numa reuni o A medida que o projecto avan a as actividades de monitora o de riscos
14. desenvolvimento de software 49 A aus ncia duma metodologia adequada no processo de desenvolvimento de software arrasta consigo s rios riscos que reflectem directamente na baixa qualidade do produto fazendo com que se torna dif cil a sua manuten o s novas altera es dos requisitos face a din mica do desenvolvimento crescente do mercado 50 CAP TULO VI CAUSAS E CONSEQUENCIAS DE RISCO E INCERTEZA Este cap tulo apresenta o resultado de uma an lise dos riscos que teve por objectivo tentar equacionar um conjunto de causas que provavelmente poder causar algum risco e o seu respectivo impacto no desenvolvimento de projecto de software Conforme vimos no cap tulo IV o risco no in cio declarado de uma forma geral mas com o tempo vem aparecendo novas informa es sobre o risco e poder ser dividido em v rios riscos diferentes com o objectivo de encontrar as melhores estrat gias para lidar com eles O conjunto de riscos resultantes dessa divis o do risco em certos casos poder o ser considerados as causas que tenham originado o seu aparecimento Como obvio um risco poder dar origem a um ou v rios riscos Dizer isso dizer que o risco pode ter como consequ ncia um conjunto de riscos e vice versa Se assim natural dizer que existe alguma rela o entre v rios riscos dum projecto de software 6 A causa de um risco pode ser devido a incerteza de um evento ou incerteza de uma estimati
15. e que a especifica o de todos os requisitos no in cio Um requisito vol til aquele que pode sofrer modifica es durante o desenvolvimento do sistema 10 2 4 AN LISE DE RISCOS ASSOCIADOS AO MODELO INCREMENTAL O modelo incremental foi proposto como uma resposta aos problemas encontrados no modelo cascata Este modelo fig 2 divide o desenvolvimento de software em itera es Em cada itera o s o realizadas as actividades de levantamento de requisitos an lise de requisitos projecto implementa o testes e implanta o para uma parte do sistema Esta caracter stica difere do modelo em cascata na qual essas s o realizadas uma nica vez para o sistema como um todo Levantamento Levantamento de Requisitos de Requisitos an lise de Fequisitos Implementa o an lise de Fequisitos Fig 2 Modelo Incremental Bezerra 2003 Ap s a defini o dos requisitos para uma itera o de desenvolvimento estes s o analisados projectados implementados testados e implantados Na itera o seguinte um outro subconjunto de requisitos s o considerados para serem desenvolvidos o que produz uma nova vers o ou incremento do sistema que cont m extens es e refinamentos sobre a vers o anterior Desta forma o desenvolvimento evolui em vers es atrav s da constru o incremental e iterativa de novas funcionalidades at que o sistema completo esteja constru do z Nas primeiras
16. feita a estimativa de custo do risco A exposi o total do risco para todos os riscos acima da linha de corte da tabela de risco pode fornecer um modo de ajustar a estimativa final quanto ao custo do projecto Tamb m pode ser usada para fazer uma previs o sobre o aumento prov vel do pessoal necess rio em v rios pontos do cronograma do projecto fi Probabilidade l Elevada M dia Baixa Catastr fico Moderada Cr tico Moderada Moderada Marginal Moderada Moderada Baixa Negligenci vel Moderada Baixa Baixa Figura 6 Exemplo de Matriz de Exposi o ao Risco Para ilustrar esse processo de avalia o de risco vamos a um exemplo pr tico Na an lise de risco relacionada com a reutiliza o de componentes no desenvolvimento de um software a equipa identificou que apenas 60 dos componentes programados para serem reutilizados que ser o integrados na aplica o Os outros ter o que ser desenvolvidos pela equipa A probabilidade do risco ocorrer de cerca de 70 Partindo do princ pio que o n mero de componentes que deveria ser reutilizados no sistema de 50 componentes o que quer dizer que a equipa ter que desenvolver cerca de 20 36 componentes a partir do zero Como o tamanho de um componente de 80 loc e o custo para cada loc de 500800 o custo geral impacto para desenvolver os componentes seria 20 x 80 x 500 800 000 00 e a exposi o ao risco RE 0
17. iniciam O gerente do projecto monitora factores que podem indicar se o risco mais ou menos prov vel No caso de alta rotatividade de pessoal os seguintes factores podem ser considerados 41 e Atitude geral dos membros da equipa com base nas press es do projecto e Grau com que a equipa se aglutinou e Relacionamento interpessoal entre os membros da equipa e Problemas em potencial com remunera o e benef cios e Disponibilidade de emprego dentro da empresa e fora dela A monitoriza o tem como objectivo controlar a evolu o dos riscos e das ac es tomadas para os mitigar ou anular Para tal h que recolher informa o precisa relevante e oportuna sobre os riscos apresenta la de um modo claro compreens vel e adequado pessoa a quem destinado o relat rio da situa o ver quadro 7 em anexo a Metodologias de monitoriza o dos riscos Na literatura da gest o do risco podemos encontrar muitas metodologias e ferramentas desenhadas para monitorizar riscos que utilizem as abordagens gerais destinadas gest o de projectos O quadro 8 em anexo resume esses m todos e ferramentas que s o utilizados para suportar cada uma das actividades da fase de monitoriza o b O encerramento de riscos O processo de gest o de riscos um processo interativo que continua ao longo do projecto A cada intera o as informa es dos riscos aumenta se possibilitando a tomada de decis o acerca de um determinado risco
18. m uma lista de riscos muito grande Isto faz com que n s sentimos a necessidade de termos uma ferramenta de suporte para geri los Para tal podemos utilizar uma base de dados para manter o registo dos riscos ou 32 mesmo simplesmente utilizar uma folha de c lculo Ter o registo de riscos em formato electr nica muito importante porque encoraja as actualiza es frequentes ou pelo menos simplifica o processo de actualiza o 4 4 2 An lise de riscos Uma an lise de riscos deve ser realizada sempre antecedendo um investimento Antes da organiza o iniciar um projecto um novo processo de neg cio desenvolvimento de uma ferramenta ou at mesmo uma rela o de parceria deve se identificar e assegurar os requisitos do neg cio A an lise dos riscos visa identificar os aspectos do projecto que p em em causa o seu sucesso Ao fazer se a an lise dos riscos deve se identificar a natureza de cada risco a causa de cada risco o impacto de cada risco e a possibilidade de problemas acidentais A an lise de riscos comprende tr s actividades b sicas 1 Avalia o da probabilidade e impacto do risco 2 Classifica o dos riscos 3 Ordena o dos riscos em fun o da probabilidade e impacto Cada risco pode ser decomposto numa causa e num efeito A causa tem uma probabilidade e o efeito tem uma dimens o ou impacto Miguel 2002 p 77 Durante o processo de an lise de riscos cada risco identificado c
19. mais dif cil Muitas das causas das afli es que surgem no desenvolvimento de software t m origem numa s rie de mitos que propagam confus es e mal entendidos Actualmente devido exist ncia de projectos cada vez mais complexos e com mais pessoas envolvidas a ger ncia tem uma participa o fundamental para o sucesso do projecto Mas apenas as habilidades pessoais da ger ncia n o s o suficientes para o xito do projecto necess ria a utiliza o de ferramentas que automatizem determinadas actividades e facilitem a comunica o entre os membros da equipa O desenvolvimento de software ao longo do tempo tem apresentado padr es de baixa qualidade de custos e prazos completamente ultrapassados Mas n o obstante os obst culos inerentes ao desenvolvimento de software tornam extremamente relevantes as v rias iniciativas que possam ser desenvolvidas com o objectivo de ultrapassar estas dificuldades Por isso vale a pena fazer uma an lise dos diversos esfor os que foram efectuados ao longo do tempo e perceber porque alguns n o foram totalmente efectivos na resolu o dos problemas enquanto outros bem sucedidos s o apontados como melhores pr ticas a aplicar sistematicamente Existem diversas abordagens de desenvolvimento de sistemas Diferentes tipos de problemas e desafios possuem caracter sticas diferenciadas que requerem diferentes tipos de abordagens O maior desafio est em escolher adaptar e integrar est
20. o deste tipo de projectos Miguel 2002 p 203 O modelo espiral exige compet ncia consider vel na avalia o dos riscos e depende dessa compet ncia para ter sucesso 17 CAP TULO III METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE 3 1 INTRODU O semelhan a dos modelos de desenvolvimento de software n o podemos falar de todas as metodologias existentes por elas serem in meras e variadas nesta ordem de ideia pretendemos deixar aqui uma reflex o sobre as metodologias tradicionais e metodologias geis e particularmente a metodologia Rational Unified Process RUP e Extreme Programming XP 2 A metodologia de projecto um plano para administrar um projecto qualquer e est normalmente dividida em tr s partes distintas a especifica o do escopo objectivos do projecto a especifica o das actividades executadas aplica es dos usu rios e as especifica es de como as diversas partes constituintes dever o interagir entre si Pinheiro 2004 Qualquer metodologia deve ser estruturada de modo a incluir um projecto l gico antes de constituir um projecto f sico e abordar os requisitos dos usu rios do sistema antes de considerar outras vari veis Ela tamb m deve ser interactiva ou seja novas informa es devem entrar progressivamente no projecto medida que se compreende melhor os requisitos definidos pelos usu rios a fim de corrigir desvios e eventuais falhas N o existe e nunca ex
21. os objectivos da opera o 5 Recomenda se as institui es de ensino superior a inclus o das metodologias geis nos curr culos dos cursos de inform tica Isto seria ben fica tanto para o meio acad mico que iria mostrar aos alunos novas pr ticas de desenvolvimento de software e prepar los para um mercado em expans o quanto para as comunidades de programa o e a ind stria que carecem de profissionais capacitados na aplica o de metodologias geis para acompanhar o dinamismo exigido pela economia actual 61 TRABALHOS FUTUROS Alargar o estudo a todas as empresas de desenvolvimento de software em Cabo verde de forma a recolher dados que permitam dizer em que n vel de maturidade de desenvolvimento de software as empresas se encontram Trabalho este que n o f cil devido burocracia que ainda hoje infelizmente persiste no nosso pa s Por outro lado as empresas com o objectivo de deixar transparecer uma boa imagem n o divulgam os seus pontos menos fortes limitando simplesmente aos seus pontos fortes por vezes um pouco desajustos sua pr pria realidade 62 GLOSS RIO Software s o programas de computador e toda a documenta o associada e os dados de configura o necess rios para fazer com que esses programas operem correctamente Processo de software aplica o de uma abordagem sistem tica disciplinada e poss vel de ser medida para o desenvolvimento e manuten o do software
22. ou seja alguns riscos podem ser encerrados ou podem ser adoptadas estrat gias para as mitigar A tomada de decis o do enceramento de riscos deve ser do respons vel pelo risco Este dever notificar o pessoal que originou o risco sobre a tomada de decis o de encerramento Tamb m o encerramento do risco deve ser assinado pelo chefe do projecto ou de um elemento respons vel dentro da equipa Um outro aspecto a ter enconta no processo de encerramento do risco se ele faz parte de um grupo de risco para poder tomar a decis o se deve encerrar o grupo completo ou apenas alguns riscos seleccionados dentro do conjunto Ap s o encerramento as li es aprendidas devem ser discutidas e documentadas com o processo de observa o ou mitiga o Esta informa o poder ser muito importante para o actual projecto bem como para futuros projectos da empresa Dentro dessas informa es que 42 devem ser retidas destacaremos os planos de mitiga o falhados e raz es para a sua falha rela es e depend ncias de riscos que n o eram bvias planos de mitiga o bem sucedidos acompanhados das raz es para o sucesso e dados relevantes da an lise especialmente os custos e benef cios do plano de mitiga o 43 CAP TULO V CARACTRIZA O DAS DIFICULDADES NO DESENVOLVIMENTO DE SOFTWARE 5 1 INTRODU O Fazer software n o tarefa f cil Fazer software de qualidade e entrega lo dentro dos prazos previstos ainda
23. parar para eles E as mudan as no mundo dos neg cios s o completamente imprevis veis Tudo mais no desenvolvimento de software depende dos requisitos Se n o for poss vel obter requisitos est veis ent o n o ser poss vel ter um plano de projecto est vel 5 5 RECURSOS Nos ltimos anos as organiza es de desenvolvimento de software t m aumentado sua percep o em rela o aos problemas que tipicamente as tocam Software com bugs prazos e or amentos n o cumpridos assim como insatisfa o de clientes e usu rios s o eventos muito mais frequentes do que se desejaria Todos estes problemas muitas vezes est o em grande parte relacionados ao facto de que no desenvolvimento de software se utilize m todos improvisados pelos desenvolvedores os quais por sua vez dependem muito mais do seu talento individual do que de uma s lida forma o acompanhada de m todos formais que dirijam suas actividades E se escolher alguma metodologia poder ter a dificuldade de saber escolher a melhor para o projecto em si Pois muitas vezes estas escolhas s o feitas n o em fun o daquele que melhor se adequa ao projecto mas sim daquele que a equipa capaz de saber usar com menos dificuldade se que se sabe usar alguma Estas conclus es s o reflexos do estudo efectuado sobre a realidade Cabo verdiana que revela dificuldades de alguns chefes de equipa de desenvolvimento de software em responder quais s o as metodologias utilizadas no
24. permitir que os seus empregados operem o mais eficaz poss vel E por ltimo e n o menos importante temos a subcontrata o de servi os de produ o Actualmente muitas empresas de desenvolvimento de software t m depend ncias cada vez mais de outras empresas para a consecu o das suas opera es Isto feito com o objectivo de reduzir os custos de investimentos em novos equipamentos e instala es menos encargos com pens es seguro de vida sa de e o decr scimo da necessidade de recrutar e despedir pessoas para responder aos ciclos do mercado Para al m disso permite uma maximiza o de tempo de desenvolvimento de forma que a conclus o de um produto n o coincida com a sua desactualiza o provocada pela concorr ncia e altera es dos requisitos Um outro aspecto que merece destaque no dom nio de desenvolvimento de software pelas implica es que tem na gest o de projectos a globaliza o do desenvolvimento Fazendo com que os gestores de desenvolvimento de projectos de software estejam sujeitos a ambiente mais complexos Da h que estabelecer alian as estrat gicas e desenvolvimento em conjunto com outras divis es da mesma companhia Cada um dos quais com os seus conjuntos de necessidades que exigem m todos especiais de organiza o e controlo Esta situa o torna mais complexa a gest o do risco desses projectos de desenvolvimento 47 5 3 DEFINI O DO PRODUTO A DESENVOLVER 5 3 1 Especifica es
25. processo de desenho evolucion rio As principais diferen as da XP em rela o s outras metodologias s o o feedback constante abordagem incremental e o encorajamento da comunica o entre as pessoas A maioria das regras da XP causa pol mica primeira vista e muitos n o fazem sentido se aplicadas isoladamente E a sinergia de seu conjunto que sustenta o sucesso de XP encabe ando uma verdadeira revolu o no desenvolvimento de software Soares 2001 XP enfatiza o desenvolvimento r pido do projecto e visa garantir a satisfa o do cliente al m de favorecer o cumprimento das estimativas As regras pr ticas e valores da XP proporcionam um agrad vel ambiente de desenvolvimento de software para os seus seguidores que s o conduzidos por quatro valores comunica o simplicidade feedback e coragem A finalidade do princ pio de comunica o manter o melhor relacionamento poss vel entre clientes e desenvolvedores preferindo conversas pessoais a outros meios de comunica o A comunica o entre os desenvolvedores e o gerente do projecto tamb m encorajada Procura se o m ximo poss vel comunicar se pessoalmente evitando se o uso de telefone e o envio de mensagens por correio electr nico A simplicidade visa permitir a cria o de c digo simples com o menor n mero poss vel de classes e m todos e que n o deve possuir fun es desnecess rias Outra ideia importante da simplicidade procurar imp
26. se tornam dispon veis durante o desenvolvimento do projecto o plano deve ser regularmente revisado Ainda segundo o mesmo autor gerentes de projecto experientes n o sup em que tudo correr bem pois sempre surgir o problemas de algum tipo durante um projecto As hip teses e as programa es assumidas inicialmente devem ser pessimistas em vez de optimistas preciso tentar prever todas as poss veis eventualidades no plano de projecto para que as restri es e os marcos do projecto n o tenham de ser renegociados a todo o tempo no loop do planeamento neste sentido que segundo Miguel 2002 o planeamento dos riscos destina se a permitir ao chefe de projecto descobrir aquilo que ele desconhece e a planear o modo de o tratar no futuro Desta forma o plano do projecto antecipadamente elaborado e as coisas podem ser controladas de modo mais eficaz Desta forma quando chegar o momento de dominar esses riscos o plano conter as actividades necess rias para isso E quando assim o chefe de projecto tem assim espa o de manobra Ainda segundo o mesmo autor o planeamento dos riscos visa fornecer a informa o necess ria para a escolha de uma estrat gia de desenvolvimento que tem como objectivo reduzir o risco t cnico do projecto e o risco empresarial da organiza o O sucesso de um projecto de desenvolvimento de software determinado pela sua grande parte por uma boa gest o dos riscos que eventualmente poder o
27. 34 De seguida passa se para o impacto de cada risco Ap s ter calculado o impacto de cada risco determina se o valor global do impacto O impacto global calculado a partir da m dia dos quatro componentes de risco desempenho apoio custo e cronograma Ap s ter completado as quatro primeiras colunas a tabela ordenada por probabilidade e por impacto Os riscos com alta probabilidade e alto impacto v o para o alto da tabela e aqueles com baixa probabilidade e impacto ficam na parte de baixo e assim se consegue a prioriza o de riscos de primeira ordem De seguida definida uma linha de corte na tabela ordenada A linha de corte tra ada horizontalmente em algum ponto da tabela sugere que apenas riscos situados acima da linha receber o aten o especial Riscos que ficam abaixo da linha s o reavaliados para se chegar a prioriza o de segunda ordem Por ltimo a ltima coluna contem ponteiro para um plano de atenua o monitora o e administra o de risco ou seja para uma colec o de folhas de informa o de risco desenvolvida para todos os riscos que ficam acima da linha de corte c Avalia o do risco A natureza do risco seu escopo e sua poca s o tr s factores que afectam as consequ ncias em que o risco pode ocorrer A natureza do risco indica os problemas que podem surgir se ele ocorrer Por exemplo se uma interface externa for mal definida prejudicar o in cio do projecto e dos testes que vao prov
28. 66 39 66 29 66 A descri o do contexto de um risco descreve o que quando onde como e porque do risco atrav s das circunstancias que rodeiam o risco e possibilita a sua compreens o por outras pessoas Para realizar as tarefas desta fase pode se utilizar v rias metodologias O quadro 2 em anexo mostra um resumo dessas metodologias Para cada uma das categorias apresentadas na sec o anterior h dois tipos distintos de risco riscos gen ricos e riscos espec ficos do produto Riscos gen ricos s o uma amea a potencial a todo projecto de software Riscos espec ficos do produto podem ser identificados somente por aqueles que tem um claro entendimento da tecnologia do pessoal e do ambiente que s o espec ficos do projecto em m os Pressman 2002 p 141 Um m todo para a identifica o de riscos a cria o de uma lista de risco Esta lista constitu da por um conjunto de riscos conhecidos e previs veis das seguintes subcategorias gen ricas e Tamanho do produto riscos associados dimens o geral do software a ser constru do ou modificado e Impacto no neg cio riscos associados s restri es impostas pela ger ncia ou pelo mercado e Caracter sticas do cliente riscos associados sofistica o do cliente e com a capacidade do desenvolvedor de se comunicar com o cliente a tempo e Defini o do processo riscos associados ao grau em que o pr
29. Em que os utilizadores t m alterado os requisitos ______ De excesso de press o sobre os prazos De projectos de baixa qualidade De derrapagem de Custos De controlo de configura o inadequado 4 Nos Projectos Contratados qual a percentagem de a b c d Custos de Manuten o Atritos entre empregados do cliente e a vossa equipa Altera o dos Requisitos do Utilizador Crit rios de Aceita o n o previstos 5 Responda s quest es abaixo com sim ou n o ou assinale a op o NR se n o quiser responder Quest es Sim N o NR A sua empresa j entregou alguma vez um software ao cliente fora do prazo estabelecido Tem havido reconhecimento pelo trabalho realizado pelos membros da equipa Considera que a sua equipa tem um bom esp rito de equipa Envolve os membros da equipa nas tomadas de decis es Controlam as altera es das especifica es Existem planos formais para todas as actividades do projecto O processo de desenvolvimento bem compreendido pelos membros da equipa Numa escala de 1 a 4 classifique a sua equipe em termos de Indicadores Pontos Experi ncia do chefe da equipa An lise de Performance Seguran a Desenho e Metodologias Cumprimento do prazo para a conclus o dos trabalhos N vel de aceita o dos vossos Produtos no mercado Garantia de Qualidade
30. MARCOS RAMOS DA GRA A TEMA AN LISE DE RISCOS E DIFICULDADES NO DESENVOLVIMENTO DE SOFTWARE LICENCIATURA EM ENSINO DE INFORM TICA ISE 2006 TRABALHO CIENT FICO APRESENTADO NO ISE PARA OBTEN O DO GRAU DE LICENCIATURA EM ENSINO DA INFORM TICA SOB A ORIENTA O DO ENG LIONEL LONA SAMB MESTRE EM INFORM MARCOS RAMOS DA GRA A TEMA AN LISE DE RISCOS E DIFICULDADES NO DESENVOLVIMENTO DE SOFTWARE Trabalho cient fico apresentado ao Instituto Superior de Educa o aprovado pelos membros do J ri e homologado pelo Concelho Cient fico como requisito parcial obten o do grau de Licenciatura em ensino de Inform tica sob a orienta ao do eng Lionel Lona Sambe Praia aos de de 2006 DEDICAT RIA A mem ria do meu pai minha m e Teodora da Gra a Ao meu irm o Pedro da Gra a AGRADECIMENTOS Um trabalho desta natureza acarreta sempre consigo um conjunto de d vidas de gratid o E assim sendo s o muitas as individualidades e institui es que merecem os nossos agradecimentos por responderem calorosamente s nossas solicita es Um trabalho desta natureza acarreta sempre consigo um conjunto de d vidas de gratid o E assim sendo s o muitas as individualidades e institui es que merecem os nossos agradecimentos por responderem calorosamente s nossas solicita es Em primeiro lugar queremos agradecer a Deus Nosso Senhor e Maria que nos proporcio
31. TEGORIA DE RISCOS O risco envolve duas caracter sticas Incerteza e perda Incerteza porque o risco pode ou n o acontecer isto n o h riscos 100 prov veis Perda porque se o risco tornar real consequ ncias indesejadas ou perdas ocorrer o Na an lise de riscos muito importante quantificar o n vel de incerteza e o grau de perda associados com cada risco Para conseguir isso necess rio considerar as seguintes categorias Riscos de projecto s o amea as ao plano do projecto Isto se os riscos de projecto vieram a acontecer na realidade poder o atrasar o cronograma do projecto e aumentar os custos Estes riscos identificam problemas relacionados com o or amento calendariza o quantidade e organiza o do pessoal recursos cliente e de requisitos e seu impacto num projecto de software A complexidade o tamanho e o grau de incerteza estrutural de um projecto s o tamb m factores de risco de projecto Riscos T cnicos s o problemas que possam surgir e que p em em causa a qualidade do software a desenvolver bem como o prazo de entrega do mesmo A concretiza o de um risco t cnico na realidade poder tornar a implementa o dif cil ou imposs vel Os riscos t cnicos identificam problemas potenciais de projecto de implementa o de interface de verifica o e de manuten o Riscos do neg cio s o problemas que p em em causa a viabilidade do software a ser constru do e que poder o
32. a actividade em que s o examinadas as itica Compila o ame q mitiga o E Ja tend ncias e Folha da informa o dos riscos Errado Os relat rios podem incluir e Matriz de riscos Resumos da situa o do plano de mitiga o e Gr ficos de correla o temporal Resumo da situa o dos riscos e Gr ficos temporais Resumos das tend ncias verificadas e Apresentar relat rios escritos e verbais e Apresentar formais Relato dos resultados NOTA Qualquer destes relat rios pode mostrar a situa o de riscos individuais de reas agregadas de riscos tend ncias ou um misto 12 INQU RITO A ANALISTAS GESTORES CHEFES DE EQUIPA DE DESENVOLVIMENTO DE SOFTWARE Este inqu rito foi elaborado por mim Marcos Ramos da Gra a finalista do curso de Licenciatura em ensino de Inform tica pelo Instituto Superior de Educa o ISE e tem como objectivo recolher informa es necess rias para fazer uma an lise de riscos e dificuldades de desenvolvimento de software em Cabo Verde Os dados s o confidenciais e an nimos e ser o utilizados nica e exclusivamente para a elabora o do meu trabalho de fim do curso para obter o grau de Licenciatura em ensino de Inform tica 1 Com base na sua experi ncia profissional classifique os riscos mais frequentes e os riscos mais perigosos dos projectos de Software Utilize uma escala de 1 a 5 sendo 1 os menos frequentes e os menos perigosos e 5 os mais frequentes e os mais perig
33. a o n vel seauinte do cliente Sistema construido pela Engenharia Fig 4 Modelo espiral A fig 4 indica o modo de manobra do modelo O desenvolvimento processa se em torno da origem no sentido dos ponteiros do rel gio passando pelos quatro quadrantes que representam as fases 1 a 4 atr s mencionadas O modelo em espiral uma abordagem para o desenvolvimento de software de grande porte Em cada n vel evolucion rio o desenvolvedor e o cliente entendem melhor e reagem aos riscos medida que o processo avan a Ele mant m a abordagem sistem tica passo a passo sugerida pelo ciclo de vida cl ssico mas o incorpora numa estrutura iterativa que reflecte mais realisticamente o mundo real Pressman 2002 p 141 Tamb m ele usa a prototipagem como mecanismo de redu o de risco e o mais importante que permite ao desenvolvedor aplic la em qualquer est gio da evolu o do produto Exige a considera o directa dos riscos t cnicos em todos os est gios do projecto e se for aplicado adequadamente reduz os riscos antes que eles fiquem problem ticos O modelo em espiral apresenta as seguintes vantagens gt Flexibilidade do processo mais adapt vel a altera es no desenho e nos requisitos gt Tamb m pode resultar numa mais r pida disponibiliza o para o mercado 16 gt O produto a ser entregue poder ter uma boa qualidade gt O resultado final poder ajustar se melhor aos requisitos do utiliza
34. a abordagem com as caracter sticas 44 presentes num determinado ambiente O desenvolvimento de software requer o uso de uma abordagem mais moderna associada ger ncia de projectos que responda a demanda de um ambiente distribu do A globaliza o da economia tem levado muitas organiza es a distribu rem geograficamente seus recursos e investimentos visando obter melhores resultados como maior produtividade redu o de custos minimiza o dos riscos e melhoria na qualidade Aliada a essas vantagens surge um novo problema no desenvolvimento de software que envolve principalmente a dist ncia f sica entre os participantes do processo Desta forma os j tradicionais problemas inerentes ao processo de desenvolvimento fortemente centrado nas fases de especifica o de requisitos e an lise de sistemas ganham contornos mais cr ticos Para isso necess rio adoptar linguagens de especifica o e processos de desenvolvimento mais formais e definidos Caso contr rio essa equipa distribu da pode fracassar Esse fracasso pode ser provocado pelos seguintes factores falta de coordena o dispers o geogr fica perda do esp rito de equipa e diferen as culturais Mas tamb m existem alguns factores que podem levar uma equipa distribu da ao sucesso tais como Infra estrutura de comunica o arquitectura do produto constru o de uma equipa metodologia de desenvolvimento tecnologia de colabora o e t cnicas de ger ncia
35. a linha de corte 70 Quadro 6 Estrat gias de gest o de riscos Risco Estrat gia Problemas Prepare um documento informativo para a alta ger ncia mostrando financeiras como o projecto presta uma contribui o muito importante para os organizacionais objectivos da empresa Problemas de Alerte o cliente sobre as dificuldades em potencial e a possibilidade recrutamento de atrasos investigue a compra de componentes Doen as de pessoas Reorganiza a equipa de maneira que haja mais sobreposi o de da equipa trabalho portanto as pessoas compreendam as tarefas umas das outras Componentes Substitua componentes potencialmente defeituosos por componentes defeituosos comprados e que tenha confiabilidade reconhecida Desempenho do Investigue a possibilidade de comprar um banco de dados com maior banco de dados desempenho Quadro 7 Formul rio de informa o de risco Formul rio de informa o de risco Identifica o do Data 9 07 05 Probabilidade 70 Impacto alto risco P02 4 32 Descri o Altera o dos requisitos Refinamento Contexto Subcondi o 1 Tempo muito limitada dedicado para levantamento de requisitos Subcondi o 2 Pouco envolvimento dos usu rios e cliente no processo de levantamento de requisitos Subcondi o 3 Envolvimento de pessoas erradas no processo de levantamento de requisitos Subcondi o 4 M interpreta o dos requisitos do cliente Atenua o monitora o 1 Planeia reuni es co
36. a mais s reais necessidades do cliente em virtude dos requisitos terem mudado durante o tempo de desenvolvimento Entretanto poss vel declarar detalhadamente todos os requisitos antes do in cio das demais fases do desenvolvimento de acordo com o modelo em cascata Se esta hip tese for assumida recursos poder o ser desperdi ados na constru o de um requisito incorrecto Esta falha pode propagar por todas as fases do processo s sendo detectada ap s o cliente ter come ado a utilizar o sistema Um outro problema do modelo em cascata o facto da sua aplica o no desenvolvimento de um software n o produzir informa es suficientes para que o gerente do projecto possa medir o andamento do mesmo Assim sendo n o poss vel ao gerente realizar uma boa estimativa para o tempo de implementa o com base no tempo que se levou para preparar os documentos de an lise e projecto Uma contribui o importante do Modelo Cascata para o processo de desenvolvimento de software que o processo de desenvolvimento de software deve ser sujeito disciplina planeamento e gest o Por outro lado este modelo bem documentado e favorece uma abordagem top down Sintetizando podemos dizer que o modelo Cascata tem muitas fragilidades mas ele significativamente melhor do que uma abordagem casual ao desenvolvimento de software Pode ser utilizado em pequenos projectos por ser mais f cil de atingir o objectivo que o modelo prop
37. ano integrado de gest o de riscos 2 A estrat gia mais inteligente para a gest o de risco ser preventivo Uma estrat gia preventiva come a muito antes do trabalho t cnico ser iniciado Riscos potenciais s o identificados avaliadas as suas probabilidades impacto e tamb m s o classificados por import ncia De seguida a equipe estabelece um plano para administra los O objectivo principal evitar riscos mas como imposs vel evitar todos a equipa trabalha para desenvolver um plano de conting ncia que vai permitir responder de modo controlado e efectivo Ap s ter se analisado e priorizado os riscos deve ser feito um julgamento sobre quais s o os riscos mais importantes a serem considerados durante o projecto z Esse julgamento o resultado de uma combina o da probabilidade do risco surgir e do impacto daquele risco De um modo geral todos os riscos catastr ficos devem sempre ser considerados como tamb m todos os riscos s rios que tenham mais do que uma probabilidade moderada de vir a ocorrer O n mero certo de riscos a ser monitorado depende do projecto e pode ser no total de cinco ou quinze Embora haja quem recomenda identificar e monitorar os dez maiores riscos Mas o mais importante que o n mero de riscos escolhido deve ser gerenci vel Um n mero muito grande de riscos simplesmente poder se ia exigir que muitas informa es fossem colectadas A partir do quadro 5 em anexo poder se ia con
38. avelmente trazer problemas de integra o do sistema no fim do projecto A poca de um risco considera quando e quanto tempo o impacto ser sentido E por fim o escopo de um risco mostra a severidade com sua distribui o geral quanto do projecto ser afectado ou quantos clientes ser o prejudicados Para determinar as consequ ncias gerais de um risco conveniente seguir os seguintes passos 1 Determinar o valor m dio da probabilidade de ocorr ncia de cada componente de risco 2 Determinar o impacto de cada componente 3 Completar a tabela de risco e analisar os resultados como descrito na sec o anterior 35 d Exposi o ao risco Para se avaliar um determinado risco h que estabelecer valores reais para gt O impacto o preju zo ou efeito sobre o projecto caso o risco ocorra gt A probabilidade probabilidade de ocorr ncia do risco gt A data de ocorr ncia per odo em que ser necess ria uma ac o a fim de atenuar o risco A exposi o ao risco risk exposure RE um atributo do risco derivado de dois outros o impacto perda e a probabilidade A exposi o ao risco definida pela seguinte rela o Boehm 1989 p 6 ER Prob Ri x Perda Ri Em que Prob Ri a probabilidade de ocorr ncia de um risco Ri e perda Ri a perda para as partes afectadas caso esse risco se materialize A exposi o ao risco pode ser calculada para cada risco da tabela de risco assim que
39. com que as propostas financeiras fiquem aqu m dos custos reais de desenvolvimento Um outro problema que as empresas nacionais enfrentam a inexist ncia de uma cultura de assist ncia t cnica p s venda por contrato 59 RECOMENDA ES Depois de ter feito um an lise profundo sobre o resultado do estudo realizado sobre os riscos de desenvolvimento de software no nosso pa s e o seu impacto sobre o mercado estamos em condi es de fazer algumas recomenda es aqueles que desenvolvem ou que pretendem desenvolver software de forma a alerta los a tomar consci ncia das reais dificuldades e o risco que poder o vir a enfrentar no desenvolvimento de software no nosso pa s 1 Hoje em dia a desenfreada penetra o de softwares de gest o importados tem influ do negativamente no desenvolvimento de softwares nacionais por se tratar de um mercado pequeno desprovido da cultura tecnol gica Face a esta avalancha de importa o alimentada pela falta de credibilidade nas capacidades t cnicas dos desenvolvedores nacionais recomenda se desenvolver software para satisfazer situa es pontuais e sempre por encomendas dos clientes 2 urgente que as empresas nacionais de desenvolvimento de software fa am um planeamento adequado antes de come ar a desenvolver software e que utilizem m todos formais de desenvolvimento S assim poder o vencer a concorr ncia evitar o desperd cio de esfor os em projectos de software que poder
40. comprometer o projecto ou o produto Os prov veis 5 riscos principais de neg cio s o 1 Construir um produto ou um sistema excelente que ningu m realmente quer risco de mercado 2 Construir um produto que n o se encaixa mais na estrat gia geral de neg cios da empresa risco estrat gico 3 Construir um produto que a equipe de vendas n o sabe como vender 4 Perda de apoio da ger ncia superior devido a mudan a de enfoque ou de pessoal risco gerencial 5 Perda de comprometimento or ament rio ou de pessoal risco or ament rio Pressman 2002 p 141 Riscos conhecidos s o aqueles que podem ser descobertos ap s a avalia o cuidadosa do plano de projecto do ambiente t cnico e comercial no qual o projecto est sendo desenvolvido e de outras fontes de informa o confi veis p ex prazo de entrega irreal falta de documenta o de requisitos ou do escopo do software e mau ambiente de desenvolvimento Pressman 2002 p 141 29 4 4 PROCESSO DE GEST O DE RISCOS O processo de gest o de riscos est ilustrado na fig 5 e envolve v rios est gios identifica o de riscos an lise de riscos planeamento de riscos e monitora o de riscos Estes est gios ser o desenvolvidos neste cap tulo Identifica o An lise de Planeamento Monitora o de riscos riscos de riscos de riscos Lista de riscos Lista de riscos Planos para evitar Avalia o em potencial priorizados riscos e planos
41. cupa o que as empresas de desenvolvimento de software tem em saber qual o grau de exposi o frente s amea as capazes de comprometer os objectivos da sua opera o Metodologia a descri o de uma sequ ncia de actividades pr ticas a ser executadas durante o desenvolvimento 64 BIBLIOGRAFIA AZEVEDO Felipe Vieiralves An lise de risco online 7 Maio de 2002 citado em 15 de Abril de 2006 17 00 Dispon vel em http www cafesoftware com br imprensa artigol htm BECK K Programa o Extrema Explicada Bookman 1999 BELLOQUIM tila SEI CMM online 24 Setembro de 1998 citado em 12 de Fevereiro de 2006 17 00 Dispon vel em http www dca fee unicamp br eleri ea976 01 SEI MM htm BELLOQUIM tilia CMM Capability Matury Model com Metodologia online 12 de Agosto de 2002 citado em 10 de Mar o de 2006 10 00 Dispon vel em http www sucesues org br documentos index asp cod noticia 53 BEZERRA Eduardo Desenvolvimento incremental e iterativo online Dezembro de 2003 citado em 14 de Fevereiro de 2006 17 30 Dispon vel em http www mundooo com br php modules php name MOO Artigos amp pa showpage amp pid 20 BOEHM B Tutorial on software Risk Management IEEE Computer Society Press New York NY 1989 CARMEL E Global Software Teams Collaboration Across Borders and Time Zones Pretince Hall EUA 1999 COEN Luciana Metodologias trazem maturidade rea de TI
42. de riscos de conting ncia Fig 5 Processo de gest o de riscos 4 4 1 Identifica o de riscos A identifica o de riscos o primeiro est gio da gest o de riscos Ela uma tentativa sistem tica de especificar amea as ao plano do projecto no que toca a estimativas cronograma desempenho recursos etc Neste est gio em princ pio os riscos n o devem ser avaliados ou priorizados embora na pr tica segundo Ian Sommerville os riscos com consequ ncias muito pequenas ou com muita pouca probabilidade n o sejam normalmente levados em considera o O est gio da identifica o de riscos visa transformar incertezas acerca do projecto em riscos bem definidos que podem ser descritos e medidos Neste est gio deve se descrever o risco e definir o contexto do risco O objectivo da descri o do risco chegar a uma descri o concisa do risco que possa ser facilmente compreendida e que permita a tomada de ac es concretas e eficazes A actividade de descri o do contexto do risco evolve o registo de toda a informa o adicional respeitante s circunst ncias eventos e inter rela es dentro do projecto que possam afectar o risco Isto feito com o intuito de providenciar os projectistas a informa o 5 Adaptado de Sommerville 2003 p 72 30 adicional do risco suficiente de modo a segurar a compreens o do significado original do risco por outras pessoas a medida que o tempo vai passando 39
43. desenvolvimento de software como velha ambi o de contribuir nesta rea que ainda n o conseguiu conquistar o seu lugar no mercado Cabo verdiano O objectivo fundamental deste trabalho levar a cabo uma investiga o que evidencie os efeitos negativos da m gest o dos riscos e apresentar alternativas quanto identifica o e o que fazer para evitar ou lidar com os riscos Sendo a pr tica o crit rio da verdade nada melhor que aprender com os erros dos outros e fazer com que os outros aprendam com o trabalho que ora se realize procurando sempre transmitir conhecimentos que permitam tratar os problemas dos riscos inerentes s actividades da gest o de projectos assim como reduzir as incertezas associadas s macro vari veis dum projecto e o impacto do sucesso ou insucesso do mesmo nos resultados da organiza o Dada a inexist ncia de um estudo do caso em Cabo Verde fomos obrigados a fazer um levantamento da situa o real quanto aos riscos e dificuldades que os profissionais da engenharia de software enfrentam no nosso pa s utilizando diversos m todos cient ficos nomeadamente entrevistas e inqu ritos Assim sendo a primeira quest o a surgir foi a seguinte Sendo o sucesso do desenvolvimento de um software determinado pela an lise e gest o de riscos quais s o as caracter sticas das dificuldades observadas no desenvolvimento de software e quais os riscos mais comuns e perigosos de projectos de software d
44. dologias geis surgiram com a proposta de aumentar o enfoque nas pessoas e n o nos processos de desenvolvimento Al m disso existe a preocupa o de gastar menos tempo com documenta o e mais com resolu o de problemas de forma iterativa As abordagens tradicionais s o tamb m chamadas de pesadas ou orientadas a documenta o elas surgiram em um contexto de desenvolvimento de software muito diferente do actual Na poca o custo de fazer altera es e correc es era muito alto uma vez que o acesso aos computadores eram muito limitado e n o existiam modernas ferramentas de apoio ao desenvolvimento do software como depuradores e analisadores de c digo Por isso o software era todo planeado e documentado antes de ser implementado As abordagens do tipo tradicional identificam uma sequ ncia de passos a serem completados e bastante controversa especialmente em projectos muito complexos mesmo assim tem conquistado adeptos em n meros crescentes Na abordagem tradicional distinguimos cinco est gios no desenvolvimento de um projecto inicia o planeamento produ o monitora o e fechamento de projecto Bugs um erro involunt rio de programa o que pode n o ser respons vel pelo bloqueio de uma aplica o programa ou sistema operativo mas que causa alguns problemas na opera o ou utiliza o Matos 2004 pp 56 19 Nem todos os projectos v o seguir todos estes est gios j que projectos pode
45. dor satisfazendo assim as necessidades dos clientes gt A manuten o dos projectos feita com uma dimens o reduzida por exemplo 2 a 3 analistas programadores em dois a tr s meses de dura o O modelo em espiral pode desenrolar de muitas formas distintas sendo cada uma dessas formas um modelo de processo em si dependendo das circunstancias do projecto Embora seja poss vel usar o Modelo em espiral directamente num projecto mais til olhar para um certo n mero de poss veis processos da espiral que ocorrem frequentemente no desenvolvimento de software Miguel 2002 P 209 No que respeita aos pontos fracos deste modelo podemos dizer que ele menos determinista e de gest o mais dif cil sendo dif cil gest o determinar a situa o de um projecto em qualquer momento assim como estimar quantas espirais s o necess rias para um projecto O modelo em espiral tem um risco de processo maior do que o modelo cascata por ser mais dif cil prever o n vel de qualidade que o produto vir a ter num determinado momento ficando cada vez mais dif cil efectuar compromissos com os clientes Torna se igualmente dif cil determinar o estado do produto em termos da sua disponibilidade para sua comercializa o em qualquer momento Os processos tradicionais de medida e as m tricas por eles utilizadas por exemplo densidade de defeitos ou perfil cumulativo de falhas n o se revelam muito teis para a gest
46. e 10 3 t m um controlo de configura o inadequado Quanto aos projectos contratados os custos de manuten o s o cerca de 15 E cerca de 2 7 dos projectos t m verificado atritos entre o cliente e a empresa contratada Os utilizadores t m alterado os requisitos em cerca de 20 Em Cabo Verde cerca de 83 das organiza es que desenvolvem software j entregaram pelo menos um software fora do prazo estabelecido Os estudos mostram que no nosso pa s sempre tem havido reconhecimento do trabalho realizado pelos membros das equipas e h um bom esp rito de equipa no seio das organiza es Os gestores chefes de equipa sempre envolvem os membros das equipas nas tomadas de decis es e tamb m sempre controlam as altera es das especifica es A fig 8 mostra os indicadores das equipas de desenvolvimento de software numa escala de O a 4 pontos 55 Indicadores das equipas de desenvolvimento de software a e 5 PN Pa 109 ge quot e Fig 7 Indicadores das equipas de desenvolvimento de software A fig 7 mostra que em Cabo Verde no que toca experi ncia dos chefes de projecto a maioria deles considera que tem uma boa experi ncia e uma boa an lise de performance no desenvolvimento de software Demonstra tamb m que os produtos das organiza es de desenvolvimento de software em Cabo Verde t m uma boa garantia de qualidade e um bom n vel de aceita o no mercado O mesmo n
47. enas 60 dos componentes planeados possam ser integrados no software em constru o o que quer dizer que h necessidade de fazer cerca de 40 dos restantes componentes sob medida Esta condi o poder ser refinada do seguinte modo Subcondi o 1 Certos componentes reutiliz veis foram desenvolvidos por terceiros sem conhecimento dos padr es internos do projecto 37 Subcondi o 2 O padr o de projecto para as interfaces de componentes n o foi consolidado e pode n o estar de acordo com alguns componentes reutiliz veis existentes Subcondi o 3 Certos componentes reutiliz veis foram implementados em uma linguagem que n o est dispon vel no ambiente alvo Ap s o refinamento do risco as consequ ncias do risco continuam na mesma isto 40 dos componentes ter o que ser constru doS sob medida mas o refinamento ajuda a isolar os riscos subjacentes e poder levar a uma an lise e uma resposta mais f cil 4 4 3 Planeamento de riscos Planeamento de riscos o est gio de gest o de risco onde s o tra ados planos para enfrentar os riscos seja evitando os seja minimizando seus efeitos sobre o projecto Os objectivos da fase de planeamento s o Miguel 2002 p 91 1 Assegurar que se conhecem as origens e as consequ ncias dos riscos 2 Desenvolver planos eficazes as medidas certas para os riscos certos 3 Desenvolver planos eficientes somente as medidas necess rias ou que beneficiar o o pro
48. esenvolvidos em cabo verde Para alcan ar os objectivos preconizados utilizamos uma metodologia te rica empirico que foi desenvolvida em tr s fases I Fez se a an lise documental e entrevistas aos chefes gestores de projectos de desenvolvimento de software II Aplica o do inqu rito aos chefes gestores analistas de projectos de desenvolvimento de software HI An lise dos riscos mais comuns e mais perigosos com o objectivo de descobrir as eventuais causas e as consequ ncias que estes podem trazer para os desenvolvedores e para o cliente O estudo realizado mostra que poucos dos que desenvolvem software em Cabo Verde fazem planeamento adequado do projecto e raros os que utilizam alguma metodologia de desenvolvimento de software Hoje em dia com a popularidade da Internet existem v rios t cnicos que acham que programam quando na verdade o que fazem s o sistemas sem metodologia documenta o e o pior sem rumo Se programar fosse sentar no computador e come ar a criar linhas de c digos n o haveria necessidade das empresas de desenvolvimento de software contratarem analistas mas sem este especialista respons vel pelos estudos preliminares antes de come ar a programar de facto seria como um cego a andar num beco escuro N o avaliar os riscos num projecto de software ou ignora los significa para muitos adiar situa es que provavelmente deixar o de ser riscos e passar o a ser graves e complicados pr
49. fissional deve ser compat vel com os restantes membros da equipa Neste sentido torna se fundamental em qualquer empresa uma administra o voltada para a gest o de recursos humanos visto que a continuidade da sua exist ncia ser determinada pela qualidade aliada aos seus produtos ou servi os tendo como base pessoas motivadas e com alto n vel de qualidade pessoal e profissional Essas pr ticas poder o ser consultados em Beck 1999 23 3 3 O RATIONAL UNIFIED PROCESS RUP Rational Unified Process uma metodologia de projecto que descreve como desenvolver software usando t cnicas testadas e aprovadas comercialmente aplic vel a equipas de desenvolvimento de software O RUP um processo de engenharia de software bem definido e bem estruturado O RUP define claramente quem respons vel por o qu como as coisas devem ser feitas e quando faz las O RUP tamb m prov uma estrutura bem definida para o ciclo de vida de um projecto RUP articulando claramente os marcos essenciais e pontos de decis o As configura es do RUP podem ser criadas para suportar equipas grandes e pequenas e t cnicas de desenvolvimento disciplinadas ou menos formais O produto IBM RUP cont m v rias configura es e vis es de processos prontas que guiam analistas desenvolvedores e gerentes de projecto gerentes de configura o analistas de dados e outros membros da equipa de desenvolvimento em como desenvolver o software E
50. ientes para adoptar o uso de processos pesados A falta de sistematiza o na produ o de software ter como resultado a baixa qualidade do produto final al m de dificultar a entrega do software nos prazos e custos predefinidos e inviabilizar a futura evolu o do software O objectivo de um modelo de desenvolvimento proporcionar ao projecto uma estrutura que reduza os riscos Miguel 2002 P 148 Que garanta que a exposi o aos v rios tipos de risco como produzir o sistema errado ultrapassar o or amento produzir o sistema que nunca funcione etc se mantenha a um n vel considerado aceit vel Para cada desenvolvimento de software antes de escolher um modelo de processo deve se avaliar o n vel de complexidade confiabilidade e tamanho do sistema de forma a escolher a melhor que se adequa s suas caracter sticas Entre as quais destacam se as caracter sticas de incerteza no in cio ou da falta de conhecimento a cerca do sistema a ser desenvolvido de modo a dar ao projecto uma estrutura que reduza os riscos que p em em causa o sucesso do projecto A estrutura o e sistematiza o de um projecto de desenvolvimento de software s o indispens veis para a sua gest o De um projecto sem estrutura n o se pode fazer estimativas sobre o seu custo ou a sua qualidade n o se pode ter pontos cr ticos definidos e o seu progresso n o pode ser monitorizado Para evitar o fracasso de um projecto a estrutura o deve ser u
51. istir uma metodologia boa para ser a nica usada e nenhum software igual ao outro Cada software equipe processo trabalho vai ter uma metodologia diferente nunca igual E sempre se acrescentam alguns passos pois ter regras ajuda mas na hora certa temos que improvisar muita coisa e cada projecto acaba bem particular e peculiar Portanto regras demais ruim temos que segu las e sabermos virar sozinhos colocando a nossa experi ncia em pr tica 18 Num projecto quase sempre se descobre novos bugs que nos podem levar de novo ao in cio Quando assim teremos que repetir todas as etapas e isso n o tem fim pois n o existe software perfeito ou livre de bugs por isso temos que encarar os projectos como vari veis dado que eles mudam frequentemente e quase sempre acabamos nos esbarrando com o come o 3 2 METODOLOGIAS GEIS E METODOLOGIAS TRADICIONAIS Existem v rios processos de software definidos na literatura da Engenharia de Software Algumas organiza es por vezes criam o seu pr prio processo ou adapta algum processo sua realidade Entre os v rios processos existentes se destaca as metodologias abordagens tradicionais que s o orientadas a documenta o e as metodologias geis que procuram desenvolver software com o m nimo de documenta o Entre todas as metodologias geis existentes a Extreme Programming XP vem se destacando em n mero de adeptos e projectos Segundo Soares 2001 as meto
52. itera es uma vers o m nima do sistema constru da Normalmente essas primeiras itera es ocorrem de uma forma sequencial pois elas estabelecem a arquitectura geral do software Podem fazer maior uso de t cnicas de prototipagem Ap s ter estabelecido essa arquitectura algumas itera es seguintes podem ser desenvolvidas em paralelo Para ser utilizado o modelo incremental requer um mecanismo para dividir o conjunto de requisitos do sistema e aloc los a uma itera o Os factores que devem ser considerados na 11 divis o dos requisitos s o a prioridade import ncia do requisito para o cliente e o risco de cada requisito O modelo incremental defende a participa o do usu rio no processo de desenvolvimento atrav s do uso de vers es desde o in cio do desenvolvimento O que compensa qualquer falsa expectativa que um usu rio possa ter sobre a vers o inicial do sistema De facto as vers es iniciais do sistema n o cont m a implementa o de todas as funcionalidades necess rias Mas essa situa o muito melhor em compara o com o modelo cascata em que o usu rio recebe o sistema somente no final do projecto Qualquer projecto de desenvolvimento de software est sujeito a riscos e estes n o podem ser eliminados por completo Portanto todo o processo de desenvolvimento deve ter em conta esses riscos E no que toca a esse aspecto o modelo incremental tem vantagem uma vez que os riscos do projecto pode
53. iza o s o estrat gias que diminuem o impacto do risco Seguir estas estrat gias significa que o impacto do risco ser reduzido Um exemplo a utilizada quando algu m est doente mostrado no quadro 6 Planos de conting ncia s o estrat gias prontas para lidarem com o risco caso acontecer Seguir essas estrat gias significa que se o pior acontecer a equipa estar preparada e tem uma estrat gia pronta par lidar com o caso Um exemplo de planos de conting ncia a estrat gia aplicada a problemas financeiras organizacionais mostrado no quadro 6 b Mitiga o de grupos de riscos relacionados Ao analisar um conjunto de riscos deve se procurar um conjunto de coisas fundamentais 40 gt Causas e efeitos para identificar causas raiz ou efeitos comuns que necessitam ser evitados gt Inter rela es entre riscos e causas isto ciclos de rela es Como por exemplo A causa B causa C causa D causa A que podem ser quebrados ou redefinidos A mitiga o para um conjunto de riscos consideravelmente mais complexo que para um nico risco Mas a mitiga o de um conjunto de riscos inter relacionados traz muitas vantagens principalmente no que toca a rentabilidade dos planos de mitiga o atrav s de elimina o de esfor os duplicados Tamb m evita objectivos e ac es de mitiga o conflituantes Por outro lado integra os esfor os do planeamento e evita tempo desnecess rio no desenvolvimento
54. jecto e ou a organiza o 4 Produzir ao longo do tempo o conjunto correcto de ac es que minimizam os riscos e os respectivos impactos custos e prazos ao mesmo tempo que maximizam as oportunidades 5 Dar prioridade aos riscos considerados mais importantes A maioria das equipes de software ainda conta apenas com estrat gias reactivas a risco Quando uma estrat gia reactiva monitora o projecto para riscos prov veis s o reservados recursos para lidar com eles quando se tornarem problemas reais Em geral a equipe de software n o faz nada a respeito de risco at que algo se d errado Ent o a equipe corre para a ac o numa tentativa de corrigir o problema rapidamente Isso frequentemente chamado modo de combate ao fogo Pressman 2002 p 140 E quando assim o projecto estar em perigo eminente 38 Os riscos devem ser planeados por pessoas que possuem conhecimento capacidade e recursos necess rios para lidar com eles de forma eficaz Na fase de planeamento de riscos s o respondidas as seguintes quest es 1 Quem respons vel por um risco 2 O que se deve fazer e em que medida As informa es sobre o risco colhidaS na fase de identifica o e an lise de risco s o transformadAs nesta fase em ac es e decis es Nesta fase s o desenvolvidas ac es para enfrentar os riscos individuais ou conjuntos de riscos relacionados por forma a estabelecer prioridades para as ac es e criar um pl
55. lementar apenas requisitos actuais evitando se adicionar funcionalidades que podem ser importantes no futuro A aposta da XP que melhor fazer algo simples hoje e pagar um pouco mais amanh para fazer modifica es necess rias do que desenvolver algo complicado hoje que talvez n o venha a ser usado devido a mudan a dos requisitos A pr tica do feedback constante significa que o programador ter informa es constantes do c digo e do cliente A informa o do c digo dada pelos testes constantes que indicam os erros tanto individuais quanto do software integrado Em rela o ao cliente o feedback constante significa que ele ter frequentemente uma parte do software totalmente funcional para avaliar e sugerir novas caracter sticas e informa es aos desenvolvedores 22 Eventuais erros e n o conformidades s o rapidamente identificados e corrigidos nas pr ximas vers es Desta forma a tend ncia que o produto final esteja de acordo com as expectativas reais do cliente necess rio coragem para implantar os tr s valores anteriores Por exemplo n o s o todas as pessoas que possuem facilidade de comunica o e t m bom relacionamento A coragem tamb m d suporte simplicidade pois assim que a oportunidade de simplificar o software percebida a equipe pode experimentar Al m disso preciso coragem para obter feedback constante do cliente XP come a com quatro valores comunica o feedback
56. lo desenvolvimento do projecto a testarem e a melhorarem o sistema antes deste estar finalizado In cio Fim Colecta e Refinamento dos requisitos Engenharia do produto Projecto r pido Constru o Refinamento do Prot tipo do prot tipo Avalia o do prot tipo pelo cliente Fig 3 Modelo de prototipa o No modelo de prototipa o n o se produz c digo efectivo no in cio ou seja come ar a desenvolver m dulos do programa uma vez que um prot tipo pode ser usado para uma continua o do progresso do sistema ou pode ser completamente descartado O in cio do desenvolvimento formal do processo acontece s depois de algumas especifica es resultantes de experi ncias realizadas com o prot tipo forem examinadas 13 O importante para este modelo definir as regras do jogo no in cio isto o cliente e o desenvolvedor t m de estar deacordo que o prot tipo seja constru do para servir apenas para defini o dos requisitos e depois descartado E o software real submetido engenharia com o objectivo de buscar qualidade e manutenibilidade O uso de prot tipos nos ajudam quando temos um grande software para desenvolver e queremos envolver usu rio na an lise do projecto Isso d a garantia de responder cabalmente as necessidades do usu rio para com o sistema reduzindo desta forma os riscos dos requisitos O prot tipo d ao cliente uma no o das fun es do sistema A u
57. m dos pontos a ter em conta o que se consegue com a utiliza o de um modelo de processo adequado ao projecto em si com o objectivo de reduzir o risco e a incerteza e aumentar a efic cia das decis es de gest o para com o projecto O modelo do processo usado por um projecto determinado por aquilo que se sabe e por aquilo que se desconhece sobre o sistema requerido e sobre o seu futuro prov vel e desenhado para reduzir a exposi o do projecto aos riscos Miguel 2002 p 148 2 3 AN LISE DOS RISCOS ASSOCIADOS AO MODELO CASCATA O modelo cascata tamb m chamado de cl ssico ou linear modelo que requer uma abordagem sistem tica sequencial do desenvolvimento para a an lise come ar o levantamento de requisitos dever estar terminado para a fase de projecto come ar a fase de an lise dever estar terminada etc Neste modelo o projecto vai progredindo com o passar do tempo passando pelas fases que est o ilustradas na fig 1 Levantamento de Requisitos Fig 1 Etapas do modelo cascata Bezerra 2003 No modelo em cascata uma vers o de produ o do sistema de software n o fica pronta at que o desenvolvimento chegue ao final Em virtude das fases serem realizadas sequencialmente e a implanta o do sistema pode ficar muito distanciada no tempo da fase inicial Caso aconte a algum erro em alguma fase do desenvolvimento por exemplo na an lise e vier a ser reconhecido s na fase final o que
58. m gerido ele pode atrasar o ritmo do projecto Em segundo lugar a utiliza o do modelo incremental torna mais complicada a tarefa de gest o das actividades do projecto Gerir um projecto onde an lise projecto implementa o 12 testes e implanta o s o feitas em paralelo caso haja duas ou mais itera es ocorrendo ao mesmo tempo torna se mais complicado do que gerir o desenvolvimento de um sistema que utilize o modelo em cascata onde as fases ocorrem de forma sequencial Em contrapartida o modelo incremental permite a produ o de informa es consistente que ajuda o gerente do projecto avaliar a continua o do desenvolvimento A liberaliza o de uma vers o de um incremento ao usu rio para fazer uso dela no sentido descobrir os erros Logo se uma vers o produzida em um incremento tiver erros a equipe de desenvolvimento fica sabendo que a vers o tem erros tomando as devidas precau es antes de avan ar com o desenvolvimento Ao desenvolvermos software complexo e de requisitos vol teis estamos sujeitos a riscos E ao utilizarmos o modelo incremental reconhecemos os riscos como reais e tentamos atac los assim que apare am para que n o se compliquem nas fases subsequentes 2 5 AN LISE DE RISCOS ASSOCIADOS AO MODELO DE PROTOTIPA O O modelo de prototipa o fig 3 pretende ser usado principalmente para animar e demonstrar os requisitos de um sistema e ajudar os clientes e os respons veis pe
59. m o cliente e usu rios de modo a surgirem o m nimo de d vidas poss vel 2 No caso da subcondi o 1 negoceia com o cliente a possibilidade de aumentar o prazo e aumenta o tempo de levantamento de requisitos 3 Faz entrevistas as pessoas certas para poder obter os requisitos o mais cedo poss vel Administra o Plano de conting ncia disparo Exposi o ao risco calculado como sendo de 230 000 00 Reserva essa quantia no custo de conting ncia do projecto Desenvolva cronograma revisado considerando que os requisitos ter o de ser alterados Disparo passos para atenua o improdutivos em 1 09 05 Estado actual 12 07 06 Passos de atenua o iniciada Emissor R Manuel Assinado M Lopes 71 Quadro 8 Metodologias de monitoriza o e respectivas ferramentas Miguel 2002 p 110 Metodologia Ferramenta Actividades e Reavaliar os atributos dos riscos por ex Atributos e Avalia o bin ria de atributos bin rios ou tr s N veis e Avalia o de atributos com tr s e Entrevistar o pessoal do projecto n veis Recolha da e Rever documenta o t cnica e relat rios por ex informa o gr ficos PERT planos or amentos registos etc e Rever relat rios de situa o e Recolher dados de produtos do projecto usando prot tipos Os dados s o analisados e compilados em relat rios de e Gr ficos de barras situa o de acordo com as normas do projecto Relat rio de situa o da E Est
60. m ser encerrados antes do seu t rmino pois podem existir projectos sem planeamento ou monitora o e muitas vezes passam pelos est gios 2 3 e 4 m ltiplas vezes No que toca as metodologias geis podemos apontar os seguintes conceitos chave e Indiv duos e interac es ao inv s de processos e ferramentas e Software execut vel ao inv s de documenta o e Colabora o do cliente ao inv s de negocia o de contratos e Respostas r pidas a mudan as ao inv s de seguir planos Isto n o quer dizer que as metodologias geis rejeitam os processos e ferramentas a documenta o a negocia o de contratos ou o planeamento mas simplesmente eles t m import ncia secund ria quando comparado com os indiv duos e interac es com o software execut vel com a colabora o do cliente e as respostas r pidas s mudan as e altera es Projecto de software algo dif cil de se controlar Por isso necess rio utilizar metodologias que minimizam os riscos garantindo que os engenheiros de software foquem em unidades menores de trabalho 3 2 EXTREME PROGRAMMING XP XP uma evolu o do ciclo de vida baseada em prototipa o diferenciando se desta na gera o de documenta o e de um produto no fim de cada ciclo do processo mas mantendo as caracter sticas que fazem o modelo de prototipa o ser t o bem visto no mundo da engenharia de software Dentro do modelo de prototipa o temos a gera o de documen
61. m ser geridos melhor E tamb m menos custoso corrigir os erros cometidos em uma itera o se detectados quando a vers o correspondente do software come ar a ser utilizados Isso evita a propaga o de erros Se as inconsist ncias detectadas em uma vers o rec m liberada n o s o t o graves elas s o rapidamente removidas e uma nova vers o do sistema entregue ao usu rio Por outro lado se as inconsist ncias descobertas forem graves e tiverem um risco grande no desenvolvimento do sistema pelo menos a sua identifica o torna poss vel reagir a elas mais cedo sem tantas consequ ncias graves para o projecto Ou seja quanto mais cedo a equipa considerar os requisitos mais arriscados menor a probabilidade de ocorrer preju zos Os requisitos a serem considerados primeiramente devem ser seleccionados com base nos riscos que eles fornecem E os mais arriscados devem ser considerados o mais cedo poss vel Apesar do modelo incremental possuir todas as vantagens atr s referidas esse modelo n o resolve todos os problemas do desenvolvimento de software pelas seguintes raz es Primeiramente o envolvimento mais estreito do usu rio no processo de desenvolvimento e o seu constante feedback em rela o as vers es que s o liberadas resultam em uma quantidade de trabalho significativa para fazer as altera es e correc es necess rias Assim se o trabalho resultante da integra o dos requisitos em evolu o n o for be
62. ms Essentials for the internetworked enterprise 9 ed United states of America McGraw Hill 2000 PINHEIRO Jos Maur cio Santos Projectos de redes online 14 de Dezembro de 2004 citado em 14 de Janeiro de 2006 10 00 Dispon vel em http www projectoderedes com br artigos artigo entendendo as metodologias e padroes p ara projectos php PRESSMAN Roger Engenharia de software 5 ed United states of America McGraw Hill 2002 SOARES M Santos Compara o entre Metodologias geis e Tradicionais para o Desenvolvimento de Software online Dezembro de 2001 citado em 12 de Mar o de 2006 14 00 Dispon vel em http www dcc ufla br infocomp artigos v3 2 art02 pdf SOMMERVILLE Ian Engenharia de software 6 ed S Paulo Addison Wesley 2003 66 SOUZA P R Rodrigues Como investir em tecnologia com seguran a crit rios importantes para se adquirir e desenvolver software online Dezembro de 2000 citado em 5 de Mar o de 2006 15 00 Dispon vel em http teses eps ufsc br defesa pdf 5852 pdf VARAJ O Jo o Eduardo Quintela Arquitectura da gest o de sistemas de informa o 2 ed Lisboa FCA Editora de Inform tica 1998 VITIELLO Jill Fast Track into Management online 16 Julho de 2001 citado em 12 de Fevereiro de 2006 17 00 Dispon vel em http www pmi org articles 67 ANEXOS Quadro 1 Tipos de riscos Tipos de risco Riscos poss veis Os clie
63. nalo Sua 19 3 4 O Rational Unified PROCESS seas pass iasad PIADA 23 CAPITULO IV GEST O DO RISCO meme 26 dl nO DA O ion O RUIDAeiois Ee EE E TO GE eai dela 26 4 2 Objectivos da gest o de FISCOS apissnasasastrapa ani d ainda cagar dRa dai A aaa E nae das ans areia agia 27 4 3 Categoria de TISCOS cs mnpisies sara iiandneesininmal sau aaa R EE EEE EEEE TEE RE 28 4 4 Processo de gest o de riSCOS issisiiisisiirissisinisi iisi udone ii aliadas Uniao aus nie sia nlr as 29 VII 4 4 Identifica o de TISCOS success as as nda 29 Aid Analise de TISCOS pressanti AD E a SR 32 4 4 3 Planeamento de TISCOS Jaques passeatas Dessas nose oba sussa and 37 4 4 4 Monitora o de riscos cccci iii r re rcerreee racer re era aa 40 CAPITULO V CARACTER STICAS DAS DIFICULDADES QUE SURGEM NO DESENVOLVIMENTO DE SOFTWARE e eeeeereenenecenanea 43 Se Indu o pas asia braile ai a br Sa a a 43 5 2 M todos de Sestit a a ana esa as nda Va DA A RA UA TN 44 5 3 Defini o do produto a desenvolver sesanuenseresci sand Qrestnsa ncia aaa Da 47 5 4 Processo de desenvolvimento sspassssenceseparesmp av aas pedra sq uia apostas a cerca mana pao 47 Da RECUES S A RR 48 CAPITULO VI CAUSAS E CONSEQUENCIAS DE RISCO E INCERTEZA 50 6 L Altera o de TEQUISHOS renser orai eaaa E aan dd USE same opas dim Essa aA 50 6 2 Press o excessiva sobre OS prazOS axessan esrieveas
64. ncial ao progresso e o insucesso constitui muitas vezes uma componente fundamental da aprendizagem Miguel 2002 p 50 Para tal devemos aprender a equilibrar as poss veis consequ ncias negativas do risco com os benef cios da respectiva oportunidade associada O processo de gest o de riscos como todos os outros planeamentos de projecto um processo interactivo que continua ao longo do projecto Uma vez tra ado um conjunto inicial de planos a situa o monitorada A medida que as informa es sobre os riscos se tornam 27 dispon veis elas t m que ser reavaliadas e novas prioridades devem ser estabelecidas Os planos para evitar riscos e os planos de conting ncia podem ser modificados com o surgimento de novas informa es sobre os riscos Os resultados do processo da gest o de riscos devem ser documentados em um plano Esta fase deve incluir uma discuss o sobre os riscos apresentados pelo projecto uma an lise desses riscos e os planos que s o necess rios para geri los Quando for apropriado pode tamb m incluir resultados de gest o dos riscos isto planos espec ficos de conting ncia a serem activados caso o risco venha a ocorrer Os tipos de risco que podem afectar um projecto dependem do projecto e do ambiente organizacional em que o software est sendo desenvolvido Contudo muitos riscos s o considerados universais Sommerville 2003 p 71 ver quadro 1 em anexo 4 2 OBJECTIVOS DA GEST O
65. nder s exig ncias cada vez maiores de clientes e usu rios em termos de prazos custos e qualidade do produto final tila Belloquim VII INTRODU O eee eee eee eee eee ee ann nt 1 CAPITULO I FUNDAMENTA O TE RICA eee 3 1 1 Planeamento de Pr JeCtOSiusiresnessssieesrsesraksresyrc a Pe R a e pisa iene ag Ea 3 1 2 Planeamento dos riscos no desenvolvimento de software 4 Lts An lise e gest o de TisCOS ste a aa iai ES SS a a ada 5 CAPITULO Il MODELOS DE DESENVOLVIMENTO DE SOFTWARE 6 da E nin Koa L0 LOF 10 PPPE E ia Dn aneis ba Nas Da ADA raca E E EE 6 2 2 ODJECU VOS ae ieee er a a id 7 2 3 An lise dos riscos associados ao modelo CASCALA s ssssasinasaniprsanisaiipresicaotaiadisnb adaga 8 2 4 An lise de riscos associados ao modelo incremental seeeeeeeseeeeeeeeerreeresrrsserrresee 10 2 5 An lise de riscos associados ao Modelo de Prototipa o eeeeseeeseeeeeeeesreereereese 12 2 6 An lise de riscos associados ao modelo em espiral de Boehm 14 CAPITULO II METODOLOGIAS E GEST O DO RISCO NO DESENVOLVIMENTO DE SOFTWARE eres 17 SL DOdNC O sspsras saias ED GADO DS DS SO SS CLS 17 3 2 Metodologias geis e Metodologias tradicionais sesescesssnsransssnasacnr o cotesama ueasasne es 18 3 3 Extreme Programming XP casesnsussompeniasa iu ssaa bad aos ADS gads ANA A pe
66. no de atenua o e gest o dos riscos com alta probabilidade e alto impacto Esse plano deve ser revisto medida que o projecto evolui para garantir que os riscos sejam actualizados A identifica o previs o avalia o administra o e monitora o de riscos um processo que consome tempo mas tem retorno de v rios modos nomeadamente menos transtornos durante o projecto maior capacidade de acompanhar e controlar o projecto e a confian a de que adv m do planeamento da resolu o de problemas antes que eles ocorram CAP TULO II MODELOS DE DESENVOLVIMENTO DE SOFTWARE 2 1 INTRODU O O desenvolvimento de um sistema de software envolve diversas fases e em cada uma delas desenvolvem se diversas actividades O encadeamento espec fico dessas fases para constru o do sistema d se o nome de modelo de ciclo de vida ou simplesmente modelo de desenvolvimento H diversos Modelos de Ciclo de Vida A diferen a entre um e outro est na maneira como as diversas fases s o encadeadas para transformar os requisitos do cliente em um sistema para o cliente O processo de desenvolvimento de software deve ser bem definido eficiente controlado medido e gerido Para alcan ar tudo isso necess rio utilizar algum modelo de processo de software de entre os v rios modelos de processo de software ou paradigmas de engenharia de software Cada um representa uma tentativa de colocar ordem numa actividade ineren
67. no desenvolvimento de software s o 1 Press o excessiva sobre os prazos 2 Inexperi ncia de utilizadores 3 Baixa produtividade 4 Inexperi ncia do pessoal 5 M estrutura organizacional 6 Pr ticas incorrectas de gest o 7 Inexperi ncia de gestores No que toca aos riscos mais perigosos no desenvolvimento de software em Cabo Verde destacam se 1 Estimativas inadequadas de custos 2 Derrapagens or amentais 3 Fric o entre pessoal empresa cliente fornecedor 4 Baixa qualidade 54 5 Pr ticas incorrectas de gest o 6 Correc o deficiente de erros 7 Inexperi ncia de gestores 8 Estimativas inadequadas Em Cabo Verde as equipas de desenvolvimento de software t m uma taxa de insucesso de 19 3 O or amento ultrapassado em cerca de 42 sendo 22 do or amento gastos em altera es e correc es No que concerne aos projectos que inclu am algo que as organiza es n o tinham experi ncia a percentagem de 18 8 Tamb m cerca de 11 1 dos projectos n o tinham planos formais para testes e instala o do software Dos projectos de software desenvolvidos cerca de 28 6 n o chegaram ao seu t rmino Nos projectos n o contratados j desenvolvidos os utilizadores t m alterado os requisitos em cerca de 25 7 Quanto ao cumprimento dos prazos 22 8 dos projectos n o foram cumpridos e o custo ultrapassado em cerca de 22 Cerca de 12 dos softwares desenvolvidos t m uma baixa qualidade
68. nou sa de e luz para a conclus o deste trabalho Um agradecimento muito especial vai ao Eng Lionel Samb que desde muito cedo tomou a orienta o do trabalho e dedicou se muito para o seu sucesso Um obrigado minha querida m e Teodora Da Gra a pelo seu empenho na minha educa o Um obrigado aos irm os Pedro Ant nio Hirondina Arlinda Zuzu Maria e Francisca pelo apoio prestado nos momentos bons e menos bons ao longo do curso Um agradecimento extensivo minha namorada Madalena Sousa pela for a esp rito de sacrif cio e de compreens o que teve durante este ano cuidando sozinha do nosso filho Um especial obrigado aos nossos amigos Teixeira e Luis pela correc o ortogr fica deste trabalho para que pudesse ser apresentado o mais correcto poss vel Aos nossos colegas da mesma casa Miguel Otelindo e Lu s pela bonita caminhada durante todos estes anos e pelos apoios prestados Os nossos agradecimentos s o tamb m extensivos a todos os colegas do curso de inform tica pelo apoio prestado e por tudo o que aprendemos juntos ao longo do curso A todos os verdadeiros amigos que estiveram sempre dispostos a nos ajudar tanto material como moralmente A esses um muit ssimo obrigado VI Desenvolver software com o que de melhor existe tanto em termos de Gerenciamento quanto em termos de Engenharia portanto o grande desafio das organiza es de software hoje se quiserem ser capazes de ate
69. ntes n o compreendem o impacto das mudan as nos requisitos O banco de dados utilizado no sistema n o pode processar tantas Componentes do software que deviam ser integrados contem defeitos A organiza o est estruturada de maneira que diferentes ger ncias Ferramentas O c digo gerado pelas ferramentas Case ineficiente As ferramentas CASE n o podem ser integradas Requisitos S o propostas mudan as nos requisitos Tecnologia transac es por segundo como esperado que limita a sua funcionalidade Estimativa O tempo requerido para desenvolver o software subestimado O tamanho do software subestimado Organizacional s o respons veis pelo projecto Pessoal imposs vel treinar pessoal com a habilidade requerida Pessoas importantes est o doentes em per odo cruciais O treinamento necess rio para o pessoal n o est dispon vel Quadro 2 Metodologias e ferramentas utiliz veis na fase de identifica o dos riscos Miguel 2002 p 67 Actividade Descri o dos riscos Defini o do contexto dos riscos Ferramenta ou metodologia Brainstorming Relato peri dico de riscos Question rio Taxion mico Checklists de riscos Todas as metodologias acima mencionadas s o aplic veis desde que o contexto seja definido sempre que um risco identificado Descri o O pessoal do projecto identifica verbalmente os riscos medida que pensa neles proporcionando em seguida aos participantes a opo
70. o acontece com o estabelecimento de contrato cliente fornecedor bem como com o desenho e as metodologias de desenvolvimento de software em que as empresas t m algumas dificuldades A dificuldade em estabelecer o contrato cliente fornecedor provocada pela falta de credibilidade nas capacidades t cnicas de gest o e planeamento aliada concorr ncia com outros softwares importados Isto faz com que as propostas financeiras fiquem aqu m dos custos reais de desenvolvimento A dificuldade no desenho e metodologias justifica se por um lado pela falta de recursos humanos e financeiros para poder suportar a implementa o de determinados processos pesados Por outro lado que as metodologias geralmente n o s o adequadas s realidades das organiza es cabo verdianas 56 CONCLUS O O processo de desenvolvimento de software deve ser bem definido eficiente controlado medido e gerido Para alcan ar tudo isso necess rio que se utilize algum modelo de processo de software Cada modelo representa uma tentativa de colocar ordem numa actividade inerentemente ca tica importante salientar que as vantagens dos modelos descritos neste trabalho s o reais mas n o constituem panaceia que pode resolver todos os problemas do desenvolvimento de software Desenvolver software uma tarefa complexa Cada projecto diferente isto porque os requisitos as tecnologias necess rias e as pessoas envolvidas s o diferentes O que quer
71. o com a sua relev ncia actual Para isso h que interrogar isto foi um risco do projecto anterior ser que pode vir a ser um risco deste projecto E necess rio desenvolver uma lista de riscos completa isto uma que cubra n o apenas os riscos t cnicos como tamb m os riscos pol ticos que podem diminuir o moral da equipa ou os riscos organizacionais que podem afectar o desejo das pessoas em trabalhar na equipa ou um conjunto de outros riscos A an lise de causa efeito muito importante para se tornar a identifica o dos riscos ainda mais relevante Come a se com o efeito o projecto falhou e recua se nas causas a partir dai O que que poderia ter provocado a falha De que modo falharam os objectivos E o que poderia ser feito para que estas coisas n o acontecem neste projecto E assim se vai recuando at se atingir um risco que se possa come ar a tratar Com este tipo de an lise poss vel chegar s causas raiz de uma forma r pida no qual poderemos ser capazes de as atacar medida que recuamos na pesquisa das causas de um risco come amos a descobrir formas de reduzir esse risco Nesta fase de identifica o dos riscos comum pessoas come arem a fazer aquilo que poderemos considerar de an lise de riscos Mas isso n o tem problema desde que se termine o assunto principal que a elabora o de uma lista de todos os riscos potenciais Se tivermos um projecto muito grande poderemos ter tamb
72. o de um modelo 57 de processo adequado ao projecto em si com o objectivo de reduzir o risco e a incerteza e aumentar a efic cia das decis es de gest o para com o projecto Nos ltimos anos as organiza es de desenvolvimento de software t m aumentado sua percep o em rela o aos problemas que tipicamente as tocam Software com bugs prazos e or amentos n o cumpridos insatisfa o de clientes e usu rios Estes problemas est o em grande parte relacionados com o desenvolvimento de software que muitas vezes realizado atrav s de m todos improvisados pelos desenvolvedores os quais por sua vez dependem muito mais de seu talento do que de uma s lida forma o acompanhada de m todos formais para dirigir as suas actividades A implanta o das metodologias em algumas organiza es tem tido resultados significativos mas em outros nem por isso Entre os motivos que levaram ao relativo insucesso das metodologias de desenvolvimento de sistemas o facto de estes darem mais relev ncia s actividades de engenharia em detrimento das actividades de gest o Isto porque as boas t cnicas de desenvolvimento n o adiantam se o projecto como um todo mal conduzido Na realidade cabo verdiana as metodologias ainda n o conquistaram o seu lugar Cerca de 50 dos desenvolvedores ainda est o a construir software usando o m todo de codificar e consertar Os m todos formais de desenvolvimento n o s o muito utilizados
73. o desenvolvimento de software s o resultantes da omiss o ou do mau uso de metodologias e t cnicas adequadas Conforme vitiello 2001 os consumidores est o demandando rapidez no mercado porque o tempo de um projecto afecta as opera es nos neg cios Eles exigem execu o sem falhas para concretizar oportunidades de neg cios Ainda o mesmo autor destaca que o gerente de projectos tem que ter algumas habilidades para obter sucesso em suas actividades entre elas destaca a lideran a a comunica o a resolu o de conflitos a negocia o a habilidade de escutar e uma boa gest o de relacionamento 5 2 2 Ambiente da Equipa Hoje vivemos num mercado de concorr ncia recheado de ofertas dando vantagens liberdade de escolha aos consumidores de produtos com pre os cada vez mais baixo acarretando dificuldades aos produtores que labutam para superar a concorr ncia e tentar atingir os seus objectivos oferecendo produtos de maior qualidade Contudo o mercado exige que as empresas de desenvolvimento de software tenha um esp rito inovador aliada a capacidade de tra ar estrat gias que lhes permite fazer face s dificuldades inerentes ao desenvolvimento de software neste sentido que as empresas t m vindo a instituir se transforma es radicais nos seus modos de opera o de forma a ser mais competitivas Transforma es essas como a diminui o dos n veis de gest o interm dia na medida em que foi percebido que a gest o inte
74. o ficar desactualizados antes da sua conclus o desenvolver produtos que o cliente n o quer e com o risco de ficar pelo caminho motivado por uma an lise de risco inadequado Tudo isto ter reflexos positivos na conquista da credibilidade do mercado f cil manuten o e evolu o do software 2 Recomenda se aos desenvolvedores de software que para cada projecto antes de escolher um modelo de processo deve se avaliar o n vel de complexidade confiabilidade e tamanho do sistema de forma a escolher o melhor que adequa as suas caracter sticas Entre as quais destacaremos as caracter sticas de incerteza no in cio ou da falta de conhecimento acerca do sistema a ser desenvolvido de modo a dar ao projecto uma estrutura que reduza os riscos que p em em causa o seu sucesso neste mbito que n o se pode ignorar o risco e esperar que nada de grave aconte a 60 3 Durante o planeamento do futuro da empresa necess rio que a administra o garanta que todos os cuidados foram tomados para que os planos se concretizem Para tal h que fazer uma an lise de risco para poder saber quais os controlos que devem ser implementados em curto m dio e longo prazo 4 Para analisar riscos h que estudar minuciosamente os processos de neg cios que sustentam a organiza o de forma a conhecer aquilo que se quer proteger e avaliar as vulnerabilidades dos componentes de tecnologia relacionado a cada processo que possa comprometer
75. oblema ou mesmo acabar com o projecto para decidir o que fazer com o risco 25 Para cada risco identificado necess rio definir o que se vai fazer com ele O RUP sugere tr s possibilidades gt Evitar o risco implica reorganizar o projecto gt Transferir o risco reorganizar o projecto para outra pessoa ficar com o risco gt Aceitar o risco viver com o risco O RUP tem uma estrat gia interessante de tentativa de minimiza o de riscos baseada nas melhores pr ticas de desenvolvimento iterativo com cada itera o a ser baseada nos requisitos e seus riscos associados Desta maneira em vez de fechar os olhos aos riscos toma se decis es conscientes e medidas com base nas incertezas analisadas Com a utiliza o de uma metodologia de desenvolvimento de software como o RUP poss vel obter gt Qualidade de software gt Produtividade no desenvolvimento opera o e manuten o de software gt Controle sobre desenvolvimento dentro de custos prazos e n veis de qualidade desejados gt Estimativa de prazos e custos com maior precis o Apesar dos benef cios deve se ter a consci ncia de que os benef cios n o vir o de maneira imediata E necess rio adquirir treinamento adequado adapta o da metodologia no contexto no qual ela ser utilizada apoio especializado para as equipas de desenvolvimento e tempo para a absor o da metodologia 26 CAP TULO IV GEST O DO RISCO 4 1 INTRODU
76. oblemas Ao concluir este trabalho espera se que os desenvolvedores dos projectos de softwares tirem proveito do mesmo e que sirva como valioso instrumento de orienta o para gest o dos riscos de forma que num futuro pr ximo os projectos desenvolvidos a n vel nacional possam concorrer na igualdade de oportunidade com os importados CAP TULO I FUNDAMENTA O TE RICA 1 2 PLANEAMENTO DE PROJECTOS Muitas bibliografias mostram que a maioria dos projectos de desenvolvimento de sistemas fracassaram devido falta de um planeamento adequado Planeamento adequado significa ter a visibilidade real das complexidades existentes no projecto a fim de mensur las e geri las compreendendo as necessidades que envolvem a cria o do produto de software e as demais necessidades do projecto Planeamento de projectos a actividade de gest o que mais tempo consome E uma actividade cont nua e inclui organiza o do projecto estrutura o das tarefas cronograma do projecto e an lise de risco Segundo Pressman 2002 o objectivo do planeamento de projecto fornecer um arcabou o que permita ao gerente fazer estimativas razo veis de recursos custo e cronograma Essas estimativas s o feitas dentro de um quadro de tempo limitado no in cio de um projecto de software e devem ser actualizadas regularmente medida que o projecto avan a Al m disso as estimativas devem tentar definir cen rios correspondentes ao melhor e aos piores ca
77. ocesso de software foi definido e seguido pela organiza o de desenvolvimento e Ambiente de desenvolvimento riscos associados disponibilidade e a qualidade das ferramentas a ser usadas para construir o produto e Tecnologia para a constru o riscos associados complexidade do sistema a ser constru do e a novidade da tecnologia que incorporada ao sistema e Tamanho e experi ncia da equipe riscos associados t cnica em geral e experi ncia no projecto dos engenheiros de software que v o fazer o trabalho 31 Ap s a elabora o da lista de riscos um conjunto de componentes e factores de risco listado juntamente com a sua probabilidade de ocorr ncia E por fim factores de desempenho de custo e de cronograma s o discutidos no est gio da an lise de riscos Elabora o da lista de riscos A lista de riscos de um projecto pode ser compilada em reuni es de equipa a partir de experi ncia adquiridos em projectos anteriores e das listas dos riscos O chefe da equipa e a sua equipa devem proteger o projecto actual dos riscos que fustigaram o projecto anterior E se todos os membros da equipa se lembrarem dos enganos dificuldades e dos riscos n o geridos no projecto anterior rapidamente chegar o a uma lista para o novo projecto A lista de riscos de projectos anteriores constitui o ponto de partida para ajudar a identifica o de riscos do novo projecto Cada risco deve ser confrontad
78. om utilizadores fric o com gest o s nior atritos entre pessoal e fraca moral da equipa 6 5 Baixa qualidade Das poss veis causas que podem fazer com que o software tenha baixa qualidade podemos destacar as seguintes inexperi ncia dos gestores e do pessoal altera o de requisitos do utilizador estimativas e planeamento incorrecto correc o deficiente de erros e press o excessiva sobre os prazos Neste ponto destacaremos mais duas causas que podem levar o software a ter baixa qualidade e vice versa como a baixa produtividade e prazos demasiados longos A baixa qualidade poder provocar uma insatisfa o enorme no seio da equipa por n o ter conseguido alcan ar os objectivos no que toca a qualidade do produto fric o com utilizadores baixa satisfa o dos utilizadores fric o com gest o s nior elevados custos de manuten o e fraca moral da equipa 53 CAP TULO VII OS RISCOS MAIS COMUNS E MAISPERIGOSOS NO DESENVOLVIMENTO DE SOFTWARE EM CABO VERDE Este cap tulo apresenta o resultado de um levantamento que fizemos sobre os riscos e as dificuldades que as empresas de desenvolvimento de software enfrentam em Cabo Verde Para a obten o dos dados foi aplicado um inqu rito as empresas e depois fez se os c lculos com base na m dia aritm tica O estudo do caso que fizemos acerca dos riscos e dificuldades no desenvolvimento de software em Cabo Verde revelou nos que os riscos mais frequentes
79. onsiderado individualmente e feito um julgamento sobre a probabilidade e a seriedade desse risco O resultado desse Julgamento depende da experi ncia do gerente de projecto Em geral n o preciso uma avalia o num rica exacta mas essa an lise deve ter como base uma an lise com utiliza o de intervalos O quadro 3 em anexo mostra tr s n veis de detalhe poss vel para as escalas dos valores dos atributos Os resultados do processo de an lise devem ent o ser apresentados numa tabela ordenada de acordo com a seriedade do risco Obviamente que neste caso a avalia o de probabilidade e seriedade arbitr ria Para fazer essa avalia o preciso ter informa es detalhada sobre projecto processo equipe de desenvolvimento e da organiza o 33 A probabilidade bem como a avalia o dos efeitos de um risco podem se modificar medida que mais informa es sobre o risco se tornam dispon veis Por isso a cada itera o a tabela de risco deve ser actualizada Depois da identifica o dos riscos cada risco analisado para determinar a possibilidade de que venha ocorrer e o dano que vai causar se efectivamente ocorrer Depois de ter estabelecida essa informa o os riscos s o classificados por probabilidade e impacto E por fim desenvolvido um plano para administrar aqueles riscos com alta probabilidade e alto impacto O processo de an lise de riscos deve envolver especialistas em an lise de ri
80. os associados Desta maneira em vez de fechar os olhos aos riscos toma se decis es conscientes e medidas com base nas incertezas analisadas O gestor de projecto segue todo o processo da gest o de projecto O processo come a com a identifica o dos riscos seguido de um plano de projecto que inclui os requisitos a desenvolver e seguidamente se define os passos das itera es 1 Definir o plano das itera es 2 Executar a itera o 3 Avaliar a execu o 4 Revisitar a lista de riscos Estes quatro passos s o repetidos para cada itera o mas no final de cada um temos uma lista revisitada de riscos desenvolvida uma lista inicial de requisitos que s o priorizados e implementados em v rias itera es consoante a prioridade Esta prioriza o deve ser baseada nos riscos de implementa o dos diferentes requisitos tecnologias etc As primeiras itera es podem por exemplo servir como experimenta o ou defini o de um prot tipo com os requisitos cujos riscos tecnol gicos s o mais elevados Ap s as primeiras itera es pode se reavaliar os riscos do projecto e se necess rio alterar prioridades relativamente implementa o Desta maneira o RUP tenta minimizar e identificar riscos que na aproxima o tradicional s seriam detectados tardiamente verificando a qualidade e controlando os A ideia chave da gest o de risco n o esperar passivamente at o risco se materializar e tornar se um pr
81. osos RISCO FREQU NCIA PERIGOSO Altera o de Requisitos do Utilizador Pr ticas Incorrectas de Gest o M estrutura organizacional Press o excessiva sobre os prazos Baixa qualidade do software Estimativas inadequadas de custos Correc o deficiente de erros Metas n o cumpridas Derrapagens or amentais Estimativas inadequadas Ferramentas e metodologias inadequadas M tricas incorrectas Inexperi ncia de utilizadores Inexperi ncia de gestores Inexperi ncia do pessoal Fric o entre pessoal empresa cliente fornecedor Elevados custos de manuten o Baixa produtividade Projectos cancelados 13 2 Com base na sua experi ncia de analista gestor chefe de equipa de desenvolvimento de software estimaria que a b o gt A taxa de insucesso de software na sua equipa de O or amento dos projectos ultrapassado em cerca de A percentagem do dinheiro do or amento gasto em altera es e correc es de Qual a percentagem dos projectos que a sua equipa j desenvolveu e que inclu am alguma coisa que a empresa n o tinha experi ncia Qual a percentagem dos projectos que n o tinham planos formais para Testes e Instala o do Software Quantos projectos desastrosos a sua equipa j teve 3 Nos projectos n o contratados qual a percentagem a b c d e
82. p r o projecto em causa Para resumir toda essa hist ria sobre gest o de riscos oportuno lembrar uma frase do consultor Tom Gilb Se voc n o atacar os riscos do projecto activamente ent o estes ir o activamente atacar voc 1 4 AN LISE E GEST O DE RISCOS Segundo Pressman 2002 a an lise e gest o de riscos uma s rie de passos que ajudam uma equipe de software a entender e administrar a incerteza Ainda segundo o mesmo autor um risco um problema potencial pode ou n o acontecer Mas independentemente do resultado realmente importante identifica lo avaliar a probabilidade de ocorr ncia estimar seu impacto e estabelecer um plano de conting ncia para o caso de efectivamente ocorrer Ele acha que software um empreendimento dif cil e que muitas coisas podem dar errado e francamente com frequ ncia d o por essa raz o que os engenheiros de software t m que estar alertas de forma a entender os riscos e tomar medidas preventivas para evita los ou administra los Para isso h que ter uma vis o do projecto global de forma a poder reconhecer aquilo que pode dar errado o que podemos chamar de identifica o de risco Ap s isso cada risco analisado para determinar a possibilidade de que venha ocorrer e o dano que vai causar se efectivamente ocorrer Ap s estar na posse dessas informa es vez de se estabelecer a probabilidade e o impacto de cada risco E por fim desenvolvido um pla
83. parte dos clientes 2 6 AN LISE DE RISCOS ASSOCIADOS AO MODELO EM ESPIRAL DE BOEHM O modelo espiral originalmente proposto por Boehm Boe88 um modelo de processo de software evolucion rio que combina a natureza interactiva da prototipagem com os aspectos controlados e sistem ticos do modelo sequencial linear Pressman 2002 p 32 O Modelo em espiral uma contribui o significativa para a compreens o do risco no planeamento do processo de desenvolvimento de software Neste modelo o processo orientado para os riscos em vez de ser orientado para o produto Boehm afirma que o modelo em espiral integra os outros modelos como casos especiais e dependendo dos riscos presentes no projecto torna se equivalente a eles em algumas situa es Este modelo segundo Miguel 2002 p 199 procede atrav s da repeti o de um processo b sico de cinco fases 1 Determinar os objectivos alternativos e restri es 2 Avaliar as alternativas identificar e resolver riscos 3 Desenvolver e verificar o produto do n vel seguinte 15 4 Planear o pr ximo ciclo 5 Rever o resultado do ciclo An lises de requisitos basedo nos Colecta inicial de requisitos iniciais requisitos e planeamento do An lises de projecto requisitos basedo nas reac es do cliente REVIS O Decis o de LA prosseguir ou n o Planejamento baseado no o coment rio dos Prot tipo de clientes software inicia A Prot tipo de Avali
84. rm dia acrescenta pouco valor s opera es e contribui apenas para a manuten o da 46 burocracia neste sentido que muitas empresas est o a reestruturar as suas for as de trabalho com o objectivo de eliminar os m ltiplos n veis de burocracia que separam o a director a Geral do pessoal de limpeza Fazendo com que os empregados lidam cada vez menos com chefes e subordinados claramente definidos mas sim com colegas sobre quem n o tem controlo directo Permitindo desta forma um ambiente onde as decis es tenham que ser tomadas geralmente atrav s de consenso Esta elimina o de cadeiras de gest o interm dias traz uma redu o da dimens o da empresa Com isso as empresas ganham vantagens na luta contra a burocracia redu o de custos aumento de produtividade e cria o de um clima est vel e afectivo entre o pessoal Uma outra transforma o no seio das empresas tem a ver com a atribui o de poder aos empregados nos seus neg cios com clientes Como por exemplo se um cliente quiser alterar a configura o de um dado equipamento o empregado tem autoridade para garantir a altera o se tal justifica Isto feito com o objectivo de acelerar o processo de decis o e em simult neo satisfazer o cliente Esta forma de exerc cio do poder altera o papel de gestor que passa da fun o de director de actividades para a fun o de suporte das actividades isto o papel dos gestores fazer o que for necess rio para
85. rototipagem na identifica o de requisitos nem sempre ben fica isto porque algumas empresas podem encarar os prot tipos como sendo os seus inimigos adapta o ao prot tipo a efici ncia de utiliza o a aplicabilidade e o comportamento dos clientes que est o a comprar um software podem ter um impacto negativo 14 Se a maqueta do sistema for constru da sem cuidado especial pode ser que esta resolva teoricamente o problema errado ou seja aparentemente o prot tipo pode parecer muito bom e estar muito bem feito mas na realidade n o ir de encontro s necessidades dos potenciais utilizadores Para al m disso o facto de um prot tipo dar a conhecer apenas algumas partes pode levar que se menosprezem partes fundamentais do sistema tornando se incompleto Saltar passos fundamentais no desenho de um software pode levar nos solu o mais f cil e simples em vez da melhor solu o Um outro problema da prototipagem que se o prot tipo for demasiado perfeito e permitir que o utilizador navegue pelo sistema j com um grau de profundidade elevado pode fazer com que o cliente pense que o projecto j est praticamente pronto desvalorizando assim a quantidade de trabalho ainda por realizar O processo de prototipagem tem custos de produ o elevados e ocupa uma quantidade de tempo exagerada Todos estes pontos devem ser bem medidos tanto pelos engenheiros de software que est o frente do projecto como tamb m por
86. rtunidade de constru o sobre as ideias dos outros Relato peri dico obrigat rio e agendado dos riscos pelo pessoal do projecto Lista de quest es organizadas de acordo com uma Taxinomia de Riscos do Desenvolvimento de Software Listas de riscos considerados comuns em projectos de desenvolvimento 68 Quadro 3 N veis de an lise poss veis e respectivos atributos de avalia o dos riscos N vel Impacto Probabilidade Exposi o ao Risco Bin rio gt Sim gt Sim 4 valores poss veis para exposi o ao risco gt N o gt N o Impacto probabilidade Sim Sim Elevada E Sim N o Moderada M N o Sim Moderada M N o N o Baixa B 3 N veis gt Elevada E gt Elevada E 9 valores poss veis de exposi o ao risco gt Moderada M gt Moderada M Impacto Probabilidade gt Baixa B gt Baixa B E E E M M E Elevada E E B B E M M Moderada M M B B M B B Baixa B 5 N veis gt Muito elevada gt Muito elevada 25 valores poss veis para a exposi o ao risco gt Elevado E gt Elevado E impacto probabilidade gt Moderada M gt Moderada M ME ME ME E E ME Muito elevada ME gt Baixa B gt Baixa B ME M E E E M M ME M E Elevada E gt Muito Baixa gt Muito Baixa ME B ME MB E B E MB M M B ME B E MB ME MB E Moderada MB MB M M B M MB B M B B ME M Baixa B B MB
87. scos e especialistas no neg cio da empresa Esta sinergia possibilita o foco e a qualidade do projecto Uma An lise de Risco bem realizada dar informa es empresa para garantir a confidencialidade disponibilidade e Integridade das suas informa es a Previs o de risco A previs o de risco ou estimativa de risco tenta avaliar cada risco de dois modos quanto a probabilidade do risco seja real e as consequ ncias dos problemas associados ao risco se ele ocorrer Para tal necess rio desenvolver quatro actividades de previs o de risco 1 estabelecer uma escala que reflecte a probabilidade do risco 2 delinear as consequ ncias do risco 3 estimar o impacto do risco no projecto e no produto e 4 anotar a precis o da previs o de risco de modo que n o haja mal entendidos b Tabela de risco A tabela de risco ver quadro 4 no anexo fornece uma t cnica simples para a previs o de riscos Para construir uma tabela de risco a equipa de software come a por listar todos os riscos na primeira coluna da tabela Depois cada risco classificado na segunda coluna como por exemplo risco de tamanho do projecto risco de neg cio etc A probabilidade de ocorr ncia de cada risco colocada na pr xima coluna O valor da probabilidade de cada risco pode ser estimado individualmente pelos membros da equipa Cada membro da equipa opina sequencialmente at que sua avalia o da probabilidade de risco comece a convergir
88. siderar os cinco riscos que podem ter consequ ncias catastr ficas ou s rios 39 a Estrat gias de mitiga o do risco A pessoa que assumiu a responsabilidade do risco que deve decidir qual a estrat gia a seguir para a sua mitiga o A determina o de uma estrat gia de mitiga o deve prosseguir os seguintes objectivos gt Assegurar que se sabe o suficiente para se tomar uma decis o informada Escolher a abordagem adequada para uma gest o eficaz dos riscos Estabelecer objectivos de mitiga o mensur veis de modo a providenciar uma meta que possibilite a avalia o do sucesso e uma orienta o para o desenvolvimento dos planos de ac o O quadro 6 em anexo mostra poss veis estrat gias que foram identificadas para os principais riscos mostrados no quadro 5 em anexo Todas as actividades de an lise de risco t m um nico objectivo a atingir que ajudar a equipe de projecto a desenvolver uma estrat gia para lidar com o risco nesta ptica que ap s ter analisado os riscos mais importantes a equipa deve definir estrat gias para geri los Estas estrat gias podem ser divididam em tr s pontos Estrat gias preventivas s o estrat gias que reduzem a probabilidade de o risco surgir Seguir estas estrat gias significa que a probabilidade do risco surgir ser reduzida Um exemplo a utilizada para lidar com componentes defeituosos mostrado no quadro 6 Estrat gias de minim
89. simplicidade e coragem Depois disso segundo Beck 1999 s o constru das 12 pr ticas que os projectos XP devem seguir Muitas dessas pr ticas s o t cnicas antigas e testadas Al m de ressuscitar essas t cnicas XP as tem como um todo sin rgico onde cada t cnica refor a as outras H uma confian a muito grande na sinergia entre elas os pontos fracos de cada uma s o superados pelos pontos fortes de outras Uma das t cnicas mais not veis a forte nfase nos testes Enquanto todos os processos mencionam a verifica o atrav s de testes a maioria a faz de forma pouco enf tica Entretanto XP coloca a na base do desenvolvimento com cada programador escrevendo testes medida que escrevem c digo de produ o Os testes s o integrados em um processo de integra o cont nua o que leva a uma plataforma altamente est vel para futuros desenvolvimento Dentro dos diversos pontos que a XP traz para a melhoria do desenvolvimento de software e sistema de informa o aparece um que tem acompanhado as pequenas e m dias empresas que o envolvimento pessoal com os colegas de equipa Estes la os que s o fundidos com companheirismo e amizade podem trazer problemas que envolvem o lado pessoal criando se barreiras que muitas vezes podem comprometer o ambiente de trabalho e a produtividade Este facto deve ser levado em conta na contrata o de recursos humanos que al m de talento t cnica e comprometimento com o trabalho o pro
90. snes near ea ces baeas cenas quer acs 51 6 3 Metas n o cumpridas isso nisiesas sen aaa Ra US Dea Re RD a nda aaa 51 6 4 Derrapa gens OrcamentaiS a asas da LS DS A a 51 6 3 Baixa qualidades eanes et e E a PU ESA AAE AEE E T 52 CAPITULO VII OS RISCOS MAIS COMUNS E RISCOS MAIS PERIGOSOS NO DESENVOLVIMENTO DE SOFTWARE EM CABO VERDE 53 CONCLUSA Os ayr er EEE E E AO 56 RECOMENDA ES eee 59 TRABALHOS FUTUROS suas a O rd 61 GLOSS RIO Ss 2s atores a a a ai aa 62 BIBLIOGRAFIA pe a a a A a E 64 ANEXOS IX FIGURAS Figura 1 Etapas do modelo CANCARA qa aiarsadas nica ara ds arraia dir ij 8 Figura 2 Modelo Incremental qs2 s an azia riding drag nd 10 Figura 3 Modelo de prototipa o aas0s2sctasefosapadseniiccas asia sal aaalidedasisad aid osasaaaa nasce nasiaantanasad d s 12 Figura 4 Modelo espiraliissiissirsssniesissirniressiscieseonecsursrdoii seasea Spss Sra seese EEE EEs ESES TEESE in 15 Figura 5 Processo de gest o de TiSCOS ssssrssressescosssesscrsisersrseseerirrssrseresirosisesuenravsresin reena 29 Figura 6 Exemplo de Matriz de Exposi o ao RisSCoO sssesssssseseessessseessrressressresseresseesssres 35 Figura 7 Indicadores das equipas de desenvolvimento de software 33 INTRODU O A an lise de riscos constitui factor preponderante no desenvolvimento de qualquer software Da a import ncia do tema em estudo An lise de riscos e dificuldades no
91. sos de modo que o comportamento do projecto possa ser delimitado O objectivo do planeamento alcan ado atrav s de um processo de descoberta da informa o que leva a estimativas razo veis Reduzida sua forma mais simples a ger ncia de projectos a disciplina de manter os riscos de fracasso em um n vel t o baixo quanto necess rio durante o ciclo de vida do projecto O risco de fracasso aumenta de acordo com a presen a de incerteza durante todos os est gios do projecto Gest o de projectos a disciplina de definir e alcan ar objectivos ao mesmo tempo em que se optimiza o uso de recursos tempo dinheiro pessoas espa o etc Segundo Sommerville 2003 uma gest o eficaz de um projecto de software depende de um planeamento acurado do andamento do projecto O gerente de projecto deve prever os problemas que possam surgir e preparar solu es experimentais para esses problemas Um plano tra ado no in cio do projecto deve ser utilizado como guia para esse projecto 1 3 PLANEAMENTO DOS RISCOS NO DESENVOLVIMENTO DE SOFTWARE Inspirados nos estudos de Sommerville 2003 Miguel 2002 e Pressman 2002 tentamos fazer um apanhado das principais ideias e teorias defendidas por esses autores de forma a melhor compreender o tema Assim segundo Sommerville 2003 o planeamento de riscos um processo iterativo que s termina quando o pr prio projecto for conclu do A medida que as informa es sobre os riscos
92. sse produto tem sido utilizado por muitas companhias em diferentes sectores da ind stria O RUP utiliza a Linguagem Unificada de Modelagem UML e por ser flex vel e configur vel pode ser utilizado em projectos de pequeno m dio e grande porte 3 3 1 Os Princ pios do RUP N o h uma maneira exacta de aplicar o RUP uma vez que ele pode ser aplicado de v rias formas Logo ser diferente em cada projecto e organiza o Por m segundo Luiz 2004 existem alguns princ pios que podem caracterizar e diferenciar o RUP de outros m todos iterativos entre eles gt Atacar os riscos cedo e continuamente gt Certificar se de entregar algo de valor ao cliente gt Focar no software execut vel gt Acomodar mudan as cedo gt Liberar um execut vel da arquitectura cedo gt Construir o sistema com componentes gt Trabalhar junto como um time 24 gt Fazer da qualidade um estilo de vida n o algo para depois 3 3 2 Import ncia da gest o de riscos com o RUP A gest o de riscos essencial em todo o projecto e se n o for iniciada com o in cio da engenharia de requisitos pode criar grandes dissabores tanto s expectativas dos utilizadores e gestores quanto s funcionalidades do sistema e qualidade do projecto O RUP tem uma estrat gia interessante de tentativa de minimiza o de riscos baseada nas melhores pr ticas de desenvolvimento iterativo com cada itera o a ser baseada nos requisitos e seus risc
93. ssiva sobre os prazos podem ter v rias consequ ncias de v ria ordem entre os quais destacamos os seguintes fraca moral da equipa elevada rotatividade de pessoal projectos cancelados derrapagens or amentais e baixa qualidade do produto final 6 3 Metas n o cumpridas Dentro das poss veis causas que pode provocar o risco do n o cumprimento das metas podemos apontar inexperi ncia dos gestores inexperi ncia do pessoal altera o de requisitos dos utilizadores estimativas inadequadas medi es e planeamento incorrectos Por seu lado se as metas n o forem cumpridas isto podem causar consequ ncias dr sticas para o projecto e para a equipa de desenvolvimento nomeadamente fric o com utilizadores fric o com gest o s nior fraca moral da equipa projectos cancelados derrapagens or amentais e baixa qualidade do produto final 6 4 Derrapagens or amentais Das poss veis causas que podem provocar derrapagens or amentais podemos apontar as seguintes pr ticas incorrectas de gest o pessoal inexperiente altera o de requisitos do utilizador estimativas incorrectas planeamento inadequado e press o excessiva sobre os prazos Para al m dessas causas destacaria mais tr s que podem levar a derrapagens or amentais e vice versa como projectos cancelados prazos demasiado longos e metas n o cumpridas 52 As derrapagens or amentais poder o originar consequ ncias muito s rias nomeadamente fric o c
94. ta o espec fica os relat rios e a avalia o dos riscos no fim de cada ciclo Na XP o que gerado como documenta o o c digo propriamente dito evitando assim a gera o de uma grande quantidade de documenta o que deve ser actualizada exigindo muito trabalho para tal Pois o desenvolvedor deve produzir linhas de c digo e bancos de dados an lise projecto e depois actualizar os modelos gr ficos e relat rios gerenciais Essas documenta es formais existem na XP por m se recomenda que elas sejam descart veis e que a acumula o de pap is seja evitada 20 Extreme Programming XP vem fazendo sucesso por ajudar a criar sistemas de melhor qualidade que s o produzidas em menos tempo e de forma mais econ mica que o habitual Tais objectivos s o alcan ados atrav s de um pequeno conjunto de valores e pr ticas que diferem substancialmente da forma como se desenvolve software na grande maioria dos projectos E uma forma mais humana onde todos clientes desenvolvedores e demais interessados no projecto s o identificados como pessoas que falham e que acertam A estrutura de desenvolvimento criada pelo XP procura ajudar o projecto a aproveitar o que as pessoas t m de melhor e solucionar suas falhas com rapidez e seguran a XP prioriza as actividades da equipe permanentemente para evitar que trabalhos desnecess rios sejam executados Isto para poupar tempo e recursos O mais importante em XP n o trabalhar mui
95. temente confusa N o podemos descrever todos os modelos de processo existentes e ilustrar todos os pontos fracos e fortes deles neste estudo por eles serem tantos e variados o que impossibilita integr los todos neste trabalho Mas pelo menos faremos uma an lise dos riscos associados a cada um dos modelos que v o ser estudados que no nosso entender melhor adequa com os nossos objectivos para com o trabalho no que concerne gest o de riscos no desenvolvimento de software Tentaremos demonstrar os pontos fortes e fracos desses modelos escolhidos bem como o impacto deles no processo de gest o dos riscos Tamb m n o nossa pretens o descrever o funcionamento de cada modelo de processo de software Essas informa es acerca da descri o de cada modelo s o os pr requisitos para entender aquilo que vamos tratar neste cap tulo Essas informa es poder o ser encontradas em Miguel 2002 Pressman 2002 e tamb m existe uma grande quantidade de informa es sobre esses modelos dispon vel na word wide web 1 O termo modelo de ciclo de vida utilizado para descrever um modelo que visa descrever um grupo de actividades e a forma como elas se relacionam 2 2 OBJECTIVOS Muitas organiza es desenvolvem software sem usar nenhum processo Isto ocorre porque os processos tradicionais geralmente n o s o adequados s realidades das organiza es Em particular as organiza es pequenas e m dias n o possuem recursos sufic
96. tiliza o de desenhos de tela para demonstrar ao cliente como os campos v o ficar e qual ser o fluxo de manuseio faz rentabilizar o tempo e qualidade na elabora o do prot tipo porque aquilo que se v o que se alcan a Uma das desvantagens do modelo que o cliente v o que parece ser uma vers o execut vel do software e desconhece que o prot tipo apenas consegue funcionar precariamente Isto porque na pressa de faz lo rodar ningu m considera a sua qualidade global ou a manutenibilidade a longo prazo Ap s o cliente saber que o produto deve ser refeito de modo que altos n veis de efic cia possam ser atingidos o cliente reclama e exige alguns reparos para transformar o prot tipo num produto execut vel E os desenvolvedores com o desejo de terminar o trabalho o mais r pido poss vel em geral concordam O desenvolvedor frequentemente faz concess es na implementa o a fim de conseguir rapidamente um prot tipo execut vel poder usar sistema operacional ou uma linguagem de programa o inapropriada simplesmente por estar dispon vel e serem conhecidos Poder tamb m implementar um algoritmo ineficiente simplesmente para indicar uma possibilidade Com o tempo o desenvolvedor pode ficar acostumado com essas escolhas e esquecer todas as raz es por que elas eram inadequadas e h que tomar muito cuidado com isso dado que uma escolha muito abaixo da ideal se tornou parte integral do sistema A t cnica de p
97. to e produzir muito mas sim produzir a coisa certa aquilo que o cliente realmente identifica como sendo valioso para resolver seus problemas E isto dever ser feito de forma consistente segura e r pida ao longo de todo o andamento do projecto XP uma metodologia gil para equipas pequenas e m dias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente Este tipo de abordagem muito interessante para projectos de pequeno porte e que n o abarquem rotinas muito complexas onde a regra de neg cio n o facilmente compreendida dado que o XP prega que deve ser usado o m nimo ou se poss vel nada de documentos a respeito do software Se por um lado isso interessante j que o projecto parte muito rapidamente para o desenvolvimento por outro lado isso muito ruim em rela o quest o da manuten o do sistema Caracter sticas do XP gt Pequenos ciclos com concreto e cont nuo feedback gt Abordagem incremental que surge como um plano abrangente que se desenvolve durante toda a vida do projecto gt Habilidade de agenda flex vel da implementa o de funcionalidades respondendo a mudan as das necessidades do neg cio gt Confian a em testes autom ticos escritos por programadores e clientes para monitorar o progresso do software 21 gt Confian a na comunica o oral testes e c digos fonte para comunicar a estrutura e objectivo do sistema gt Confian a no
98. tuem uma regra Agora o problema o que devemos fazer a esse respeito Uma proposta a seguir na engenharia de requisitos a obten o de uma vis o completamente clara dos requisitos antes de come ar a construir o software obter uma aprova o do cliente e depois implantar procedimentos que limitam mudan as nestes requisitos Um problema com isto que apenas entender as op es para os requisitos j dif cil E mais dif cil ainda estabelecer as estimativas por v rios motivos 1 desenvolvimento de software 48 uma actividade de design portanto dif cil de planear ou custear 2 Os materiais b sicos mudam rapidamente 3 Dificuldade de previs o e quantifica o do pessoal envolvente A natureza intang vel do software tamb m contribui E muito dif cil ver o valor de uma funcionalidade do software at que ela seja materializada Apenas quando se v uma vers o preliminar do software que realmente se come a a entender as funcionalidades valiosas e as que n o s o Mesmo que se concorda e realmente se consegue um conjunto preciso e est vel de requisitos ainda assim isso provavelmente n o seria suficiente Na economia de hoje as for as de neg cio est o mudando o valor dos requisitos de software muito rapidamente O que pode ser um bom conjunto de requisitos agora n o ser um bom conjunto de requisitos em 1 ano Mesmo que os clientes possam fixar seus requisitos o mundo dos neg cios n o vai
99. va Devemos encarar ambas as causas de modo diferente pois as repostas a elas devem ser igualmente diferentes Para analisar as causas e consequ ncias de risco e incerteza escolhemos cinco riscos que melhor se adequam para este estudo quanto as suas frequ ncias e perigosidades para o projecto de desenvolvimento de software 6 1 Altera o de requisitos As poss veis causas que pode levar a altera o de requisitos no processo de desenvolvimento de software s o de natureza diversa entre as quais podemos destacar inexperi ncia de utilizadores inexperi ncia de gestores metodologias e estimativas de custos inadequadas Os eventos que estamos a falar s o eventos que n o desejamos que aconte am riscos 51 Para al m dessas causas temos mais duas causas fric o com utilizadores e fric o com gestores que poder o alterar os requisitos provocando fric o com utilizadores e gestores A altera o de requisitos poder trazer consequ ncias para o projecto nomeadamente prazos n o cumpridos derrapagens or amentais atrasos na comercializa o press o excessiva sobre prazos e enfraquecimento da moral da equipa 6 2 Press o excessiva sobre os prazos Dentro das poss veis causas que pode levar a press o excessiva sobre os prazos podemos apontar os seguintes altera o de requisitos dos utilizadores estimativas inadequadas medi es planeamento e pr ticas de gest o incorrectas A press o exce

Monografia final - Portal do Conhecimento

Contents

Download Pdf Manuals

Related Search

Related Contents