Rodrigo Brazão Teixeira
Contents
1. Teste de unidade V amp V do Integra o e gras projeto plano de teste Teste de Teste de integra o aceita o Planejar pr xima fase Desenvolver verificar Opera o produto de pr ximo n vel Figura 2 Modelo em Espiral SOMMERVILLE 2007 Em evolu o a esta linha de desenvolvimento surge metodologia gil caracterizando se pelo modo adaptativo e partilhando a ideia de que o cliente identifica suas necessidades medida que manipula o que j foi desenvolvido GARCIA et al 2005 O uso de processos no desenvolvimento de software enfrenta grandes press es considerando que a compreens o adapta o e uma gest o ativa do processo de desenvolvimento s o fatores importantes para o xito em projetos Isso melhora a qualidade reduz os custos tempo e ajuda as partes interessadas SOMMERVILLE 2004 Neste contexto o processo um arcabou o bem definido e inter relacionado que auxilia na constru o de um software de forma a atender todos os requisitos estabelecidos em um projeto com qualidade e efici ncia MADAN 1997 Ainda segundo MADAN 1997 processo definido como tarefas que constroem os requisitos estabelecidos pelo usu rio em software 2 1 METODOLOGIA TRADICIONAL O modelo tradicional marcado pela rigidez resultado da defini o de passos sequenciais bem definidos Distingue se pela formalidade controle e rigor onde o sucesso alcan ado fruto do que foi2. gil com foco em sistemas m dicos Trabalho de Conclus o de Curso apresentado ao Curso de Licenciatura em Computa o da Universidade Estadual da Para ba em cumprimento exig ncia para obten o do grau de Licenciado em Computa o Aprovada em 25 03 2014 ath Prof Dr Fred rico Moreira Bublitz UEPB Orientador AMO Anaie theo Lele Prof Msc Ana Isabella Muniz Leite UEPB Examinadora touccana de Paw voz heal Prof Dr Luciana de Queiroz Leal Gomes UEPB Examinadora An lise de processos de desenvolvimento de software tradicional e gil com foco em sistemas cr ticos BRAZ O Rodrigo Teixeira BUBLITZ Frederico RESUMO O uso de sistemas inseridos na rea da sa de se torna cada vez mais comum com a finalidade de melhorar a presta o de servi os a pacientes Sistemas como estes s o considerados como cr ticos pelo fato de que suas consequ ncias de fracasso podem gerar preju zos elevados desde danos ao meio ambiente at a morte em humanos Portanto desenvolver um software com estas particularidades n o tarefa f cil faz se necess rio o uso de um processo estruturado que se enquadre a todas as caracter sticas inerentes a esta finalidade Nesse sentido este trabalho identifica as principais metodologias existentes elenca as prioridades que devem ser observadas em sistemas cr ticos e por fim realiza um comparativo entre metodologias com foco em sistemas cr ticos identif
3. controle de processos emp rico onde itera es de feedback constituem o elemento central O software desenvolvido por uma equipe de auto organiza o por meio de fases chamadas de sprints Recursos a serem implementados no sistema est o registrados em uma carteira Em seguida o propriet rio do produto decide quais itens do backlog deve ser desenvolvido na seguinte sprint Os membros da equipe coordenam o seu trabalho em uma reuni o di ria chamada stand up Um membro da equipe o scrum master respons vel por resolver os problemas que impedem a equipe de trabalhar de forma eficaz Extreme Programming Concentra se nas melhores pr ticas para o desenvolvimento XP Consiste em doze pr ticas o jogo de planejamento fases pequenas met fora design simples teste refatora o programa o em pares propriedade coletiva integra o cont nua semana de 40hrs clientes no local e os padr es de codifica o Fonte DYBA et al 2008 Confrontando as duas metodologias vistas na se o 2 1 e 2 2 identificou se na pesquisa realizada por DYBA et al 2008 um resumo de algumas das principais diferen as entre o desenvolvimento tradicional e o desenvolvimento gil conforme apresentado na Tabela 3 a seguir Tabela 3 Principais diferen as entre Metodologias Desenvolvimento Tradicional Desenvolvimento gil Pressuposto Fundamental Os sistemas s o plenamente determi
4. dos dispositivos e sensores eletr nicos A aplica o destas tecnologias na rea m dica poder trazer diversos benef cios aos pacientes e otimizar a presta o de servi os dos profissionais da sa de Ainda segundo RENATO 2011 o uso adequado de novas tecnologias essencial nos cuidados de pacientes para amenizar erros m dicos trazendo mais seguran a no tratamento de doentes Como exemplo de sistemas na rea da sa de existe marca passo desfibriladores m quina de resson ncia dispositivos m dicos em geral Desenvolver esse tipo de sistema necessita de uma preocupa o especial quanto ao processo de desenvolvimento devido seguran a que exige pois deve atentar para requisitos como seguran a confiabilidade e integridade MADAN 1997 Essencialmente as opera es de um sistema cr tico sempre devem ser seguras de modo que nunca cause danos s pessoas ou ao ambiente mesmo em caso de falhas SOMMERVILLE 2007 A import ncia no rigor em tratar certos requisitos nestes sistemas se d pelo fato de que suas consequ ncias de fracasso podem gerar danos elevados desde danos ao meio ambiente como a morte em humanos GOVE et al 1991 Um exemplo real de acidente com sistemas cr ticos conhecido foi o Therac 25 que ocorreu entre os anos 85 e 87 envolvendo uma m quina de radioterapia atrav s de overdoses desencadeando mortes e ferimentos graves PHANT et al 2010 Uma caracter stica importante que deve ser levada em c
5. ncias s o tomadas para reduzir o risco identificado N o h medidas de seguran a seguran a sx A seguran a n o integrada no A seguran a n o integrada no Integridade de ciclo de vida do projeto ciclo de vida do projeto seguran a A verifica o feita por meio O projeto passa por testes de testes Facilita o controle dos frequentes possibilitando o riscos A documenta o reconhecimento de erros priorizada a cada etapa previamente e tomando as devidas finalizada durante o projeto resolu es evitando custos yf adicionais Isso facilita o controle Monitoramento dos riscos Com rela o a documenta o a preocupa o menor uma vez que o foco est no desenvolvimento e na entrega do produto de maior valor para o cliente no menor tempo poss vel Uma observa o a ser feita no presente trabalho com rela o ao crit rio exposto na tabela anterior que pode ser considerado o mais importante e relevante no tocante a sistemas m dicos Integridade de Seguran a pois al m de integrar a seguran a em todo o ciclo de vida do projeto o sistema deve ser estruturado de forma que seja capaz de prevenir identificar e remover amea as Assim n o houve nenhuma preocupa o com integridade de seguran a nas metodologias abordadas neste trabalho evidenciando a necessidade de rever ou adequar este quesito em um processo de desenvolvimento de software Diante da conjuntura atual em q
6. paper identifies the key available methodologies shows the priorities to be observed in critical systems and finally conduct a comparision between methodologies focusing on critical systems identifying how each one is applicable on this kind of project KEYWORDS Processes of software development Traditional Methodology Agile Methodology Critical Systems REFER NCIAS AFONSO Paulo NUNES Manuel PAISANA Ant nio BRAGA Ana The influence of time to market and target costing in the new product development success International Journal of Production Economics 2008 v 115 n 2 October 2008 pp 559 568 ISSN 0925 5273 BECK Kent BEEDLE Mike VAN Arie Bennekum COCKBURN Alistair CUNNINGHAM Ward FOWLER Martin GRENNING James HIGHSMITH Jim HUNT Andrew JEFFRIES Ron KERN Jon MARICK Brian MARTIN Robert C MELLOR Steve SCHWABER Ken SUTHERLAND Jeff THOMAS Dave Manifesto for Agile Software Development 2001 Dispon vel em lt http www agilemanifesto org gt Acesso em 07 de Agosto de 2013 BOEHM Barry TURNER Richard Using Risk to Balanc Agile and Plan Driven Methods Computer 2003 v 36 n 6 June 2003 pp 57 66 ISSN 0018 9162 COOPER Alecia Initiatives to Improve Patient Safety Perioperative Nursing Clinics 2008 v 3 n 4 December 2008 pp 287 295 COYLE Sharon CONBOY Kieran A Case Study of Risk Management in Agile Systems Development 2009 ECIS 17th European Conference o
7. rg os exigem documenta o extensa para atestar a integridade e qualidade do software WARREN 2011 O uso de processos de desenvolvimento de software seguindo o modelo tradicional para este tipo de sistema ainda sofre percal os GARCIA et al 2005 Apesar de o desenvolvimento fazer uso de extensa documenta o alguns processos a exemplo do modelo em cascata s realizam testes no fim do desenvolvimento e s se tem uma vers o funcional do sistema ap s muito tempo de desenvolvimento dificultando a gest o dos riscos e a realiza o da valida o SCOTT et al 2011 Aluno graduando em Computa o Universidade Estadual da Para ba UEPB Orientador Universidade Estadual da Para ba UEPB Em contrapartida as metodologias geis a exemplo do XP eXtreme Programming geralmente se preocupam com o desenvolvimento de testes medida que o sistema desenvolvido e sempre h uma vers o funcionando a cada itera o otimizando o time to market AFONSO et al 2008 As metodologias geis t m como caracter sticas a adaptabilidade e agilidade em tratar erros ou requisitos inesperados no ciclo de vida do projeto Com este des gnio gil requisitos como efic cia qualidade flexibilidade facilitam o alcance de resultados satisfat rios e aceit veis em projetos SOMMERVILLE 2007 Entretanto n o dada significativa aten o documenta o e especifica o formal que importante num sistema cr tico Com i
8. uma abordagem sugerida por Royce em 1970 SANTOS 2004 onde a ideia principal a sequ ncia de etapas definidas por meio de atividades fundamentais como an lise e defini o de requisitos projeto de sistema e software implementa o e testes de unidade integra o e testes de sistemas opera o e manuten o na qual cada etapa compreende em um documento aprovado e uma etapa s se inicia ap s o t rmino da anterior SOMMERVILLE 2007 Figura 1 Modelo em Cascata SOMMERVILLE 2007 Mas com o tempo notou se que o modelo tamb m tinha suas restri es por m funcionou de modo satisfat rio no desenvolvimento de sistemas operacionais e compiladores Em seguida o m todo espiral ganhou notoriedade MISRA et al 2012 Este modelo observado na Figura 2 representado como um espiral onde cada itera o representa uma fase num total de quatro que envolve defini o de objetivos avalia o e redu o de riscos desenvolvimento e valida o e planejamento SOMMERVILE 2007 Esses modelos descrevem um m todo de desenvolvimento a chamada metodologia tradicional Determinar objetivos alternativas e restri es Avaliar alternativas identificar resolver riscos An lise de risco An lise de risco An lise de risco Revis o Plano de requisitos Plano de ciclo de vida Conceito de opera o Valida o de requisitos Plano de desenvolvimento
9. 1530 1605 SOMMERVILLE I Software Engineering 2004 Addison Wesley Reading MA SOMMERVILLE I Engenharia de Software 2007 Addison Wesley Reading 8 Edi o MA WARREN C Axelrod Applying Lessons from Safety Critical Systems to Security Critical Software Systems Applications and Technology Conference LISAT 2011 IEEE Long Island May 2011 pp 1 6 WUNRAM Jurgen A strategy for identification and development of safety critical software embedded in complex space systems Acta Astronautica 1993 v 29 n 3 March 1993 YLIMANNELA Ville A Model for Risk Management In Agile Software Development 2012 Dispon vel em lt http www cloudsw org under review a6f468c9 4857 4206 96ee f67df0583d41 file initial version gt Acesso em 16 09 2013
10. BOK Guide 4 ed 2008 ISBN 978 1 933890 70 8 PRESSMAN R S Engenharia de Software 6 ed McGraw Hill 2006 RENATO Alexandre Rodrigues de Souza Desafios e Oportunidades no Desenvolvimento de Produtos Eletr nicos com Software Embarcado na Area M dica 2011 Dispon vel em lt http ubiq inf ufpel edu br arrsouza lib exe fetch php media artigo_topicos pdf gt Acesso em 15 01 2014 SANTOS Michel Soares Compara o entre Metodologias geis e Tradicionais para o Desenvolvimento de Software 2004 Dispon vel em lt https www google com br url sa t amp rct j amp q amp esrc s amp source web amp cd 1 amp ved 0CCoQFjAA amp ur l http 3A 2F 2Fxps project googlecode com 2Fsvn 2F svn 2Fbc 2F6 2Ftrunk 2Foutros 2FMet Ageis pdf amp ei CG8XU7zIF4jKkAfD30CgDg amp usg AFQICNFQAzq2EGASz8JilenpBOA488UgmA amp bvm bv 622 86460 d eWO amp cad rja gt Acesso em 15 01 2014 SCOTT G Gazelle SANTOS Isa C T ROCHA Lu s A TAVARES Jo o Manuel R S Desenvolvimento de Dispositivos M dicos Vantagens de uma Metodologia Dedicada 2011 In CIBEM Dispon vel em lt http paginas fe up pt tavares downloads publications artigos CIBEM 2011 IsaCTSantos pdf gt Acesso em 11 11 2013 SIPONENA Mikko BASKERVILLEB Richard KUIVALAINENA Tapio Integrating Security into Agile Development Methods System Sciences 2005 HICSS 05 Proceedings of the 38th Annual Hawaii International Conference on Jan 2005 pp 185a ISSN
11. Universidade ESTADUAL DA PARA BA UNIVERSIDADE ESTADUAL DA PARA BA CAMPUS I CENTRO DE CI NCIA E TECNOLOGIA DEPARTAMENTO DE COMPUTA O CURSO DE GRADUA O EM LICENCIATURA EM COMPUTA O RODRIGO BRAZ O TEIXEIRA An lise de processos de desenvolvimento de software tradicional e gil com foco em sistemas m dicos CAMPINA GRANDE PB 2014 RODRIGO BRAZ O TEIXEIRA An lise de processos de desenvolvimento de software tradicional e gil com foco em sistemas m dicos Trabalho de Conclus o de Curso apresentado ao Curso de Licenciatura em Computa o da Universidade Estadual da Para ba em cumprimento exig ncia para obten o do grau de Licenciado em Computa o Orientador Frederico Moreira Bublitz CAMPINA GRANDE PB 2014 T266a Teixeira Rodrigo Braz o An lise de processos de desenvolvimento de software tradicional e gil com foco em sistemas m dicos manuscrito Rodrigo Braz o Teixeira 2014 19 p il color Digitado Trabalho de Conclus o de Curso Gradua o em Computa o Universidade Estadual da Para ba Centro de Ci ncias e Tecnologia 2014 Orienta o Prof Dr Frederico Moreira Bublitz Departamento de Computa o 1 Desenvolvimento de software 2 Metodologia tradicional 3 Metodologia gil 4 Sistemas cr ticos T tulo 21 ed CDD 005 2 RODRIGO BRAZ O TEIXEIRA An lise de processos de desenvolvimento de software tradicional e
12. al 2010 3 1 3 ESTIMATIVA DE SEGURAN A De acordo com ISO 2007 a ISO 14971 detalha um processo que identifica perigos associados ao desenvolvimento de produtos destinados a sa de e estima os riscos destes perigos Assim a estimativa de risco a redu o da incerteza onde se estabelece uma associa o entre um evento e uma a o de seguran a determinando a extens o do risco COYLE et al 2009 Para isso uma equipe de risco de prefer ncia multidisciplinar analisa os riscos de um sistema e ao t rmino da analise ter uma ordem de riscos priorizando os mais graves dos mais leves e em seguida proposto medidas de controle determinando um limite aceit vel entre os riscos identificados Na vis o de PROJECT MANAGEMENT INSTITUTE 2008 importante destacar que as medidas tomadas devem se ajustar a relev ncia do risco Dessa forma uma placa de risco pode ser utilizada para evidenciar os riscos de maior e menor prioridade identificados por notas vermelhas e amarelas respectivamente e com um X marcando a nota de risco j tenha sido tratada Isto permite que a equipe de desenvolvimento tenha maior visibilidade dos riscos que j foram ou ainda ser o tratados YLIMANNELA 2012 3 1 4 INTEGRIDADE DE SEGURAN A Preferencialmente os sistemas devem ser simples mas de seguran a atestada evitando ao m ximo a possibilidade de erro Segundo EDUARDO et al 2007 Seguran a considerada um requisito n o funcional
13. arciais do produto proporcionando uma visibilidade maior do software e feedbacks simult neos pelo mesmo MISRA et al 2012 A seguir encontra se a descri o dos principais m todos geis de desenvolvimento de acordo com a pesquisa realizada por DYBA e DINGSOYR 2008 Tabela 2 Principais M todos geis M todo gil Descri o Crystal O m todo centra se na comunica o em pequenas equipes de desenvolvimento de software O desenvolvimento tem sete caracter sticas entrega frequente melhoria reflexiva comunica o osm tica aberta para ouvir e intervir no ambiente de comunica o seguran a pessoal o foco f cil acesso a usu rios experientes e os requisitos para o ambiente t cnico Feature driven Combina desenvolvimento gil orientado por modelo com nfase development no modelo inicial de objeto a divis o do trabalho em recursos e Desenvolvimento design interativo para cada recurso Uma itera o de um recurso orientado a consiste em duas fases concep o e desenvolvimento funcionalidade Lean software Uma adapta o dos princ pios da produ o enxuta Consiste em development sete princ pios eliminar o desperd cio ampliar o aprendizado decidir o mais tarde poss vel entregar o mais r pido poss vel capacitar equipe construir integridade e ver o todo Scrum Concentra se em gerenciamento de projetos em situa es em que dif cil de planejar com anteced ncia com mecanismos para
14. associa es entre um evento risco e uma a o de seguran a e Integridade de seguran a o crit rio mais importante onde o sistema deve ser capaz de realizar opera es automaticamente visando prever detectar e eliminar um risco e Monitoramento Verificar e controlar os riscos conhecidos al m de produzir relat rios que comprovem esta constata o A seguir ser discorrido sobre cada crit rio 3 1 1 IDENTIFICA O DE RISCOS Segundo COYLE et al 2009 esta a fase mais importante no tratamento de risco e tem como finalidade perceber as poss veis amea as de um sistema com anteced ncia de modo que Um Guia do Conhecimento em Gerenciamento de Projetos minimize seus efeitos ou at os anule como tamb m se evite maiores erros custos e o fracasso do projeto importante que cada risco identificado receba uma breve descri o de risco para facilitar a percep o no momento em que o recurso for tratado pela equipe de desenvolvimento Sugere se que haja uma lista de verifica o para identificar os pontos de alto risco A identifica o de um risco pode ocorrer nas reuni es de planejamento e pode gerar muito tempo Aconselha se ainda classificar o risco baixo m dio alto para visibilidade da equipe por meio de notas com cores vermelha por exemplo para riscos de alto impacto e probabilidade YLIMANNELA 2012 monitorada atrav s de an lises de seguran a de software durante todo o processo Assim p
15. e ocorrer um inc ndio ele poder ser controlado antes que ameace a aeronave 3 1 5 MONITORAMENTO Comumente o foco est na parte da engenharia de software na busca de entender e especificar ao m ximo o software e minimizar os erros mas se d pouca aten o a constante verifica o de software e neste ponto que sistemas complexos necessitam de aten o Assim rever ou adaptar o processo de desenvolvimento se faz necess rio para aplica es cr ticas WUNRAM 1993 Segundo GOVE et al 1991 idealmente o sistema cr tico deve se enquadrar num estado seguro por m ainda que o sistema n o esteja em um estado propriamente dito seguro este pode ser considerado seguro se ele pode se recuperar de um estado perigoso Mas atingir este patamar em um projeto n o tarefa f cil importante tamb m que haja uma avalia o do Software com rela o a sua seguran a para certificar e atestar que o sistema atende a todos os requisitos de seguran a Essas informa es ficam registradas num relat rio ou documenta o contendo todos os resultados do processo de testes PHANI et al 2010 Esta documenta o necess ria e ser apresentada posteriormente a rg os reguladores a fim de obter certifica o do sistema desenvolvido De acordo com PROJECT MANAGEMENT INSTITUTE 2008 importante tamb m controlar os riscos fazendo acompanhamentos e avalia es cont nuas durante todo o projeto desde riscos j identificados at no
16. esenvolvimento gil a abordagem utilizada possibilita que novos requisitos sejam inseridos durante o ciclo de vida sem afetar o todo uma vez que d suporte as mudan as que possam surgir E se tratando do tratamento de riscos a metodologia n o enfoca a an lise de riscos esta ocorre de forma muito sucinta pois almeja entregas r pidas de software destinando menos tempo a an lises e planejamento e Estimativa de Seguran a De acordo com o que foi exposto na se o 3 2 2 a estimativa a redu o da incerteza estabelecendo uma a o de seguran a para cada risco identificado Nesse sentido identifica se que apenas a metodologia tradicional realiza esse tratamento entretanto de um modo geral as medidas tomadas s o com foco em risco de projeto ou seja as iniciativas tomadas est o associadas ao sucesso ou fracasso do projeto desviando se do foco do presente trabalho que voltado a riscos de produto e Integridade de Seguran a Em vista ao exposto na se o 3 2 3 nenhuma das metodologias vistas preocupa se com seguran a no que diz respeito a arquitetar o sistema para que perigos sejam evitados detectados removidos ou at mesmo que inclua solu es de prote o minimizando os resultados de um acidente caso aconte a e Monitoramento Ambas as metodologias monitoram o que est sendo desenvolvido a partir de testes possibilitando um maior feedback do software desenvolvido e como observado na se o 3 este um crit rio fa
17. icando como cada metodologia se aplica diante de projetos como este PALAVRAS CHAVE Processos de desenvolvimento de software Metodologia Tradicional Metodologia Agil Sistemas Cr ticos 1 INTRODU O Com o avan o tecnol gico o n mero de produtos de software desenvolvidos para automatizar atividades do nosso cotidiano vem crescendo Esses sistemas s o aplicados nas mais diversas reas sempre visando otimizar os processos e ou reduzir os custos SOMMERVILLE 2007 Uma tend ncia o desenvolvimento de sistemas para assist ncia sa de que motivada principalmente pela necessidade de redu o de custos mediante a conjuntura atual em que a popula o global est envelhecendo e necessita de mais cuidados com a sa de Assim como afirmado por COOPER 2008 esses sistemas atuam principalmente na automatiza o de processos para melhorar o atendimento de pacientes viabilizando uma melhoria na qualidade de vida deles Sistemas desenvolvidos com foco na rea m dica s o considerados e tratados como cr ticos pois lidam com vidas tendo um elevado ndice de risco que no caso de falha podem acarretar desde uma les o morte de um paciente Sistema cr tico aquele que pode causar danos a vida ou ao ambiente GOVE et al 1991 Esses sistemas s o regulados por normas e certifica es de qualidade que atestam a seguran a do software desenvolvido Mas atingir os padr es de seguran a exigidos n o tarefa simples Esses
18. n veis previs veis e s o constru dos atrav s de um planejamento meticuloso e extenso Software adaptativo de alta qualidade desenvolvido por pequenas equipes que usam o princ pio do design cont nuo de aperfei oamento e testes com base no feedback r pido e mudan as Estilo de Gest o Comando e controle Lideran a e colabora o Gest o de Conhecimento Expl cito Impl cito Comunica o Formal Informal Modelo de Desenvolvimento Ciclo de vida do modelo cascata espiral ou alguma Modelo de entrega evolutiva varia o Mecanicistas burocr tica Org nico flex vel Pretens o Organizacional com a alta formaliza o participativa incentivando a Forma Estrutura destinada a grandes a o cooperativa social organiza es destinada a pequenas e m dias organiza es Planejamento denso e Controle cont nuo dos Controle de Qualidade controle rigoroso requisitos de design e Testes solu es Teste cont nuo Fonte DYBA et al 2008 3 SISTEMAS CR TICOS O desenvolvimento de sistemas cr ticos est sendo amplamente empregado em diversas reas a exemplo de sistemas de avia o usinas nucleares e na assist ncia sa de principalmente em dispositivos m dicos LINDHOLM et al 2011 Segundo RENATO 2011 Estamos em uma poca de r pido avan o tecnol gico da comunica o m vel da computa o embarcada e miniaturiza o
19. n Information Systems Dispon vel em lt http aisel aisnet org ecis2009 3 gt Acesso em 21 10 2013 DYBA Tore DINGSOYR Torgeir Empirical Studies of Agile Software Development a Systematic Review Information and Software Technology 2008 v 50 n 9 10 pp 833 859 ISSN 0950 5849 EDUARDO Carlos de Barros Paes MASSAKI Celso Hirata RUP extension for the development of secure systems Emerald International Journal of Web Information Systems 2007 v 3 n 4 pp 293 314 GARCIA Edes da Costa Filho PENTEADO Ros ngela COUTINHO J nia Anacleto Silva VACCARE Rosana Teresinha Braga Padr es e M todos geis agilidade no processo de desenvolvimento de software 2005 Dispon vel em lt http sugarloafplop2005 icmc usp br papers 9673 pdf gt Acessado em 07 08 2013 GOVE R A HEINZMAN J L Safety criteria and model for mission critical embedded software systems Computer Assurance 1991 COMPASS 91 Systems Integrity Software Safety and Process Security Proceedings of the Sixth Annual Conference on 1991 pp 69 73 Jun 1991 ISO 2007 ISO 14971 Medical devices Application of risk management to medical devices 2nd Edition IWOHARA Steven K LIU Dar Biau A Verification Tool to Measure Software in Critical Systems Reliability and Maintainability Symposium 1995 Proceedings Annual Jan 1995 pp 315 320 ISSN 0149 144X LINDHOLM Christin NOTANDER Jesper Pedersen HOST Martin Software Risk A
20. nalysis in Medical Device Development Software Engineering and Advanced Applications SEAA 2011 37th EUROMICRO Conference on 2011 Sept 2011 p 362 365 MADAN Sanjay Techniques to facilitate development of safety critical software systems Electrical and Computer Engineering 1997 Engineering Innovation Voyage of Discovery IEEE 1997 Canadian Conference on 1997 v 1 May 1997 pp 249 252 ISSN 0840 7789 MAINART Domingos de A SANTOS Ciro M Desenvolvimento de Software Processos geis ou Tradicionais Uma vis o cr tica 2010 Dispon vel em lt http www enacomp com br 2010 cd artigos completos enacomp2010_4 pdf gt Acesso em 05 08 2013 MCCAFFERY F BURTON J RICHARDSON I Improving Software Risk Management in a Medical Device Company Software Engineering Companion Volume 2009 ICSE Companion 2009 31st International Conference on 2009 May 2009 pp 152 162 MISRA Subhas KUMAR Vinod and Uma Kumar FANTAZY Kamel AKHTER Mahmud Agile software development practices evolution principles and criticisms Emerald International Journal of Quality amp Reliability Management 2012 v 29 n 9 pp 972 980 PHANI S Kumar SEETHA P Ramaiah KHANAA V A Methodology for Building Safer Software Based Critical Computing Systems Advance Computing Conference IACC 2010 IEEE 2nd International Feb 2010 pp 422 429 PROJECT MANAGEMENT INSTITUTE PMI Um guia do conhecimento em gerenciamento de projetos PM
21. o a objetos onde o desenvolvimento em m dulos somado ao processo de integra o se encaixa nos conceitos do paradigma Possui ainda uma fase que trata de riscos Incremental Assume que o software desenvolvido pode sempre crescer e agregar novas funcionalidades sendo que cada uma dessas funcionalidades ou o conjunto delas ser desenvolvido por um incremento que segue todas as etapas descritas no modelo linear Cascata um modelo sequencial dividido em fases distintas sem possibilidades de altera o ideal para projetos com requisitos bem definidos e compreendidos Cada fase inicia se ap s o t rmino da anterior Fonte MAINART et al 2010 SANTOS 2004 e EDUARDO et al 2007 2 2 METODOLOGIA GIL A metodologia gil surgiu em 2001 atrav s do Manifesto gil proposto por BECK et al 2001 um grupo de dezessete especialistas em processos que juntos propuseram conceitos e princ pios comuns entre os m todos de desenvolvimento doze no total que regem e auxiliam no desenvolvimento gil Destes princ pios destacam se a maior prioridade satisfazer o cliente mudan as inesperadas nos requisitos s o bem vindas e entregar frequentemente o software funcionando Nos m todos geis busca se constantemente o desenvolvimento de pr ticas que minimizem os ndices de erros em projetos por meio de t cnicas geis GARCIA et al 2005 T m como objetivo a satisfa o do cliente por meio de entregas p
22. ogia Tradicional da Metodologia gil respectivamente J na se o 3 detalha caracter sticas importantes quanto ao desenvolvimento de sistemas com caracter sticas cr ticas feita uma introdu o e posteriormente s o elencados crit rios que estes sistemas devem se enquadrar conforme verificado na literatura pesquisada Na se o 4 faz se um comparativo unindo as metodologias apresentadas com os crit rios destacados identificando quais processos inerentes a cada metodologia se enquadram nesses crit rios estabelecidos E na se o 5 apresentada a conclus o do trabalho realizado 2 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Os processos de desenvolvimento de software surgiram numa poca de crise de software onde se fez necess rio sistematizar o trabalho de forma consistente para solucionar problemas cada vez maiores e mais complexos Assim houve a necessidade de tornar o processo de desenvolvimento estruturado e unificado atendendo a todas as necessidades de uma forma compensadora MAINART et al 2010 Historicamente um dos primeiros modelos de processos de desenvolvimento de software foi o modelo de c digo e corre o que se baseava em duas etapas escrever o c digo e em seguida corrigir os poss veis problemas do c digo MISRA et al 2012 Adiante um processo que se firmou durante anos foi o m todo em cascata de desenvolvimento suprindo limita es de outros modelos O modelo em cascata mostrado na Figura 1
23. onta no desenvolvimento de um sistema cr tico a confiabilidade pois se o mesmo n o oferecer confian a seus usu rios n o ir o querer fazer uso dele como tamb m ir o generalizar a qualidade de outros produtos da mesma empresa e em decorr ncia disso os custos dessa falha ser o muito maiores SOMMERVILLE 2007 Neste sentido o uso de crit rios bem definidos buscando garantir a efic cia de um sistema se faz necess rio 3 1 CRIT RIOS DE SEGURAN A De acordo com PROJECT MANAGEMENT INSTITUTE 2008 o risco a incerteza que caso ocorra afeta um dos objetivos do projeto Esses objetivos envolvem custos cronograma escopo e qualidade Com isso o risco pode ter diversas causas e impactos Neste sentido o processo de desenvolvimento de um sistema cr tico requer an lises e conceitos mais estruturados para lidar com esta proposta WUNRAM 1993 Assim com base na literatura pesquisada verificou ser uma constante no tratamento de risco alguns crit rios base Desse modo utilizou se o guia PMBOK como refer ncia principal e foram elencados cinco crit rios que compreendem em e Identifica o de riscos Identificam se eventos que possam amea ar ou afetar a qualidade e funcionalidades do software e An lise de Riscos e amea as Ftapa em que se reflete sobre os riscos identificados seus poss veis danos e como o trabalho deve seguir diante deles priorizando os de maior probabilidade e Estimativa de seguran a Estabelece
24. ou a qualidade de um sistema e que deve ser considerado em todo o ciclo de desenvolvimento De acordo com PHANI et al 2010 seguran a de software envolve Integrar a seguran a no ciclo de vida do software Analisar o software sistema e interfaces do come o ao fim Planos de seguran a de documenta o decis es processos e resultados Rastrear os requisitos de seguran a de software em todas as fases de software e Relat rios e resolu o de problemas e diverg ncias Segundo SOMMERVILLE 2007 a chave para garantir a seguran a assegurar que o acidente n o ocorra ou que as consequ ncias de sua ocorr ncia sejam nfimas e isso pode ser conseguido de tr s maneiras e Preven o de perigos O sistema projetado para que os perigos sejam evitados Por exemplo um sistema de corte que requer que o operador pressione dois bot es separados simultaneamente para operar a m quina evita o perigo de as m os do operador estarem no caminho da l mina e Detec o e remo o de perigos Perigos devem ser detectados e removidos antes de causarem um acidente Por exemplo um sistema de uma ind stria qu mica pode detectar a press o excessiva e abrir uma v lvula de al vio para reduzir a press o antes que ocorra uma explos o e Limita o de danos Deve incluir solu es de prote o que minimizem os danos resultantes de um acidente Por exemplo um motor de aeronave normalmente inclui um extintor autom tico de inc ndio S
25. planejado PRESSMAN 2006 Segundo MAINART e SANTOS 2010 apud Oliveira seu foco principal conhecer todos os requisitos antes do projeto iniciar possibilitando um melhor planejamento facilitando a ger ncia e mantendo o processo rigoroso Ainda segundo MAINART e SANTOS 2010 As metodologias consideradas tradicionais tamb m chamadas de pesadas t m como caracter stica marcante serem divididas em etapas e ou fases Essas fases s o muito bem definidas e englobam atividades como An lise Modelagem Desenvolvimento e Testes Um processo que marca essa proposta e muito utilizado at hoje o Modelo em Cascata ou Modelo Cl ssico SANTOS 2004 em que a sequ ncia priorizada de forma que uma etapa s se inicie ap s o t rmino da anterior e a cada etapa finalizada uma documenta o deve ser aprovada para in cio da seguinte Em suma um processo disciplinado de tarefas na constru o de um projeto buscando garantir as exig ncias do cliente no tempo e custos previstos EDUARDO et al 2007 A seguir encontra se a s ntese de alguns dos principais processos inerentes metodologia tradicional segundo as pesquisas realizada por MAINART e SANTOS 2010 SANTOS 2004 e EDUARDO e MASSAKI 2007 Tabela 1 Principais M todos Tradicionais M todo Tradicional Descri o Espiral O Modelo Espiral um modelo iterativo muito utilizado no desenvolvimento de softwares em conjunto com o paradigma da orienta
26. po de dispositivo Mas em vista aos dados observados os processos geis s o mais eficazes no que se refere ao time to market entretanto apresenta se inferior no comparativo entre metodologias enquanto o rigor encontrado na metodologia tradicional se apresenta mais adequado para desenvolver um sistema m dico Com isso conclui se que os processos de um modo geral atendem parcialmente ao tratamento de riscos sendo necess rias algumas reformula es para atender de forma eficiente a perspectiva esperada para esta linha de desenvolvimento Assim como sugest o de trabalhos futuros prop e se abordar dois processos um tradicional e um gil fazendo um misto das duas metodologias moldando a a fim de cobrir o tratamento de riscos e de seguran a integrando a caracter stica de time to market da metodologia gil buscando a disponibiliza o mais r pida do sistema e adequando o para aprova o por parte dos rg os reguladores de software m dicos ABSTRACT The use of software systems in healthcare have been increasingly common in order to improve the delivery of service to patients Systems like these are considered as critical by the fact that the consequences of a failure can cause considerable harms from environment damaged to death of people Therefore developing a software with these features isn t too easy because it s necessary to use a structured process that meets all characteristics inherent to this purpose In this sense this
27. recisam ser reconhecidos todos os riscos para serem considerados durante todo o desenvolvimento PHANT et al 2010 3 1 2 AN LISE DE RISCOS E AMEA AS De acordo com PROJECT MANAGEMENT INSTITUTE 2008 esta an lise avalia o grau e as consequ ncias de ocorr ncia de um risco Faz se a jun o dos riscos e o planejamento sobre que decis o tomar no decorrer do projeto tomando como refer ncia todos os poss veis riscos Nesse contexto a seguran a um fator predominante que deve estar incluso durante todo o ciclo de vida do software pois garante que o sistema n o oferecer perigo aos usu rios e a atividade que dirige se essa garantia a gest o de riscos MCCAFFERY et al 2009 Vale ressaltar que importante identificar os principais requisitos de seguran a classific los bem como apontar as pessoas autorizadas que possam interferir na seguran a do software Ou seja definir pessoas espec ficas a lidar com determinados assuntos garantindo a seguran a do todo onde certos assuntos ficam sob sigilo dos principais respons veis do software SIPONENA et al 2005 Segundo BOEHM et al 2003 tamb m necess rio prover de uma base para tomar decis es quanto estrat gia de desenvolvimento S o identificados os candidatos a risco possibilitando a an lise e servindo como guia no aux lio ao planejamento Assim revis es extensivas s o essenciais durante o processo de desenvolvimento orientado seguran a PHANI et
28. sso na vis o de SIPONENA et al 2005 faz se necess rio um processo de desenvolvimento de software que atenda as propriedades inerentes a sistemas m dicos e de uma maneira dedicada e gil Nesse contexto o desenvolvimento de sistemas na rea da sa de requer uma abordagem dirigida que al m de auxiliar na condu o do processo de desenvolvimento tamb m se enquadre no tratamento de requisitos espec ficos que estes produtos de software necessitam Dessa forma os processos podem auxiliar de modo ativo todas as particularidades de sistemas cr ticos minimizando o trabalho da equipe de desenvolvimento Assim levanta se a quest o da pesquisa Como os processos de software d o suporte ao desenvolvimento de sistemas cr ticos com foco em sa de Com isso o presente trabalho busca fazer an lises de processos na literatura existente para identificar e avaliar dentre as metodologias quais processos melhor se relaciona no foco em riscos ressaltando o foco em risco de produto que atenta para a preven o e seguran a de software e se os mesmos necessitam ser remodelados para serem aceitos por rg os reguladores do sistema de sa de caso n o haja nenhuma proposta adequada para esta linha de desenvolvimento O artigo se estrutura por meio de se es que embasam cada uma delas Assim a se o 2 exp e um pouco a cerca dos Processos de desenvolvimento de software como surgiram e alguns exemplos Na se o 2 1 e 2 2 diferenciado a Metodol
29. ue tecnologias est o sendo inseridas para facilitar as atividades do dia a dia e por outro lado aten o est voltada aos cuidados com a sa de e a qualidade de vida esta constata o importante visto que proporciona uma contribui o consider vel a futuras pesquisas pois evidencia a necessidade de que sistemas m dicos sejam arquitetados para realizar opera es autom ticas e imediatas incluindo preven o identifica o e remo o que limitem os preju zos caso um dano venha a ocorrer Integrar tais caracter sticas em um processo de desenvolvimento de software um passo inicial e primordial para assegurar que pacientes submetidos a tratamentos por meio de sistemas m dicos estar o seguros 5 CONCLUS O E TRABALHOS FUTUROS Como observado na an lise realizada o trabalho visava identificar como os processos de desenvolvimento de software existentes se aplicam no desenvolvimento sistemas na rea da sa de uma vez que requerem enfoques mais estruturados e direcionados para lidar com esta proposta onde o quesito seguran a deve ser tratado durante todo o ciclo de vida do software Dessa forma foi poss vel perceber que os processos existentes n o tratam em espec fico do requisito de seguran a este considerado apenas como um requisito normal e sendo tratado dessa forma n o o suficiente para assegurar a qualidade de um sistema m dico nem obter certifica o objetivando a adequa o de normas destinadas a este ti
30. vor vel no que diz respeito ao controle do software Outro questionamento que pode ser levantado em rela o ao enfoque gil quanto a sua utiliza o em sistemas cr ticos pelo fato de destinar pouca aten o a documenta o Ser que com uma documenta o menor poss vel obter a certifica o de software Assim sob a tica de sistemas cr ticos voltados a rea m dica h controv rsias quanto a sua utiliza o em processos geis pois h uma necessidade consider vel de documenta o extensa para apresenta o e comprova o junto a rg os reguladores atestando detalhadamente a efic cia e qualidade do software cr tico A tabela a seguir apresenta o resumo baseado nos crit rios abordados neste comparativo entre de metodologias Tabela 4 Resumo Comparativo com base em Crit rios de Risco Crit rios de compara o Desenvolvimento Tradicional Desenvolvimento gil Identifica o de riscos A identifica o ocorre de forma mais criteriosa por meio de 4 planejamento antes que o projeto inicie O risco visto como um requisito normal Tenta minimizar os riscos com desenvolvimento em releases curtos ou seja identificado durante o projeto An lise de riscos e amea as Reconhecimento expl cito de risco visto como algo que 4 pode amea ar o projeto ou dar errado Direcionamento menor em an lises Risco considerado um elemento cotidiano Estimativa de Provid
31. vos riscos facilitando a ado o de medidas corretivas 4 COMPARATIVO DE METODOLOGIAS O comparativo entre processos tem como objetivo avaliar o progresso do processo de desenvolvimento de software identificando vantagens e desvantagens que sirvam de base na redu o de erros e qual a melhor abordagem a ser utilizada no tratamento de riscos em sistemas cr ticos na rea da sa de Como p de ser visto anteriormente nesta pesquisa na se o 3 alguns crit rios apresentados se fazem necess rios para realizar esta compara o e Identifica o de Riscos A metodologia tradicional prioriza o conhecimento de todos os requisitos pertinentes ao projeto e a partir deles estruturado o planejamento que define o desenrolar da execu o das etapas do processo No tocante a identifica o do risco propriamente dito h o reconhecimento de riscos j no desenvolvimento gil o foco mais importante o desenvolvimento e entregas r pidas com isso riscos que possam surgir no decorrer do projeto s o tratados em reuni es r pidas chamadas de stand up meetings e An lise de Riscos e Amea as No desenvolvimento tradicional o controle do projeto se baseia nos requisitos j estabelecidos o risco visto como algo que pode amea ar o projeto ou dar errado dessa forma uma provid ncia tomada para reduzir o risco identificado por m se surgir no decorrer do desenvolvimento um requisito ou um risco inesperado o todo tem que ser revisto No d
Download Pdf Manuals
Related Search