From: Subject: Por que usar Engenharia de Software Date: Fri, 4 Feb 2005 14:51:41 -0200 MIME-Version: 1.0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Content-Location: http://www.medsolution.com.br/claudio/esepep.htm X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Por que usar Engenharia de Software

Uma Revis=E3o sobre Engenharia de Software e sua = Utiliza=E7=E3o no=20 Desenvolvimento de Sistemas de Prontu=E1rio Eletr=F4nico de=20 Pacientes

Claudio Giulliano Alves da Costa, MD,

Rodrigo Paulo Quaresma, BE e Renato Marcos Endrizzi = Sabbatini,=20 PhD.

N=FAcleo de Inform=E1tica Biom=E9dica, Universidade = Estadual de=20 Campinas, Campinas/SP, Brasil

O desenvolvimento de um Prontu=E1rio Eletr=F4nico de = Pacientes=20 (PEP) deve ser norteado segundo metodologias preconizadas pela = Engenharia de=20 Software (ES), que permitem uma perfeita organiza=E7=E3o do processo de=20 desenvolvimento, bem como um resultado final de alt=EDssima qualidade. = Este artigo=20 descreve brevemente a disciplina de ES, seus m=E9todos, ferramentas e = paradigmas,=20 enfatizando seu uso no desenvolvimento de PEPs. Assuntos como = gerenciamento de=20 projetos, m=E9tricas, estimativas e estudo de viabilidade s=E3o = discutidos; an=E1lise,=20 projeto, codifica=E7=E3o, testes e manuten=E7=E3o s=E3o detalhados, = citando-se os=20 principais m=E9todos; e por fim, s=E3o feitos coment=E1rios sobre a = garantia da=20 qualidade de software. Destaca-se ainda, a utiliza=E7=E3o das = ferramentas CASE.=20 Desta forma, o intuito deste artigo =E9 despertar a aten=E7=E3o da = comunidade que=20 desenvolve solu=E7=F5es na =E1rea de sa=FAde para a import=E2ncia da ES = no desenvolvimento=20 de PEPs.

INTRODU=C7=C3O

O desenvolvimento de sistemas de Prontu=E1rio = Eletr=F4nico de=20 Paciente (PEP) est=E3o em pleno "vapor", diversas institui=E7=F5es e = empresas, em todo=20 mundo, est=E3o desenvolvendo suas solu=E7=F5es, muitas tem equipes = especializadas que=20 produzem softwares de qualidade, outras, entretanto, n=E3o tem uma = vis=E3o definida=20 do processo de desenvolvimento, e acabam produzindo sistemas de m=E1 = qualidade=20 t=E9cnica, sem atingir as expectativas de usu=E1rios e diretores. No = primeiro caso,=20 temos um processo de desenvolvimento que segue uma s=E9rie de = princ=EDpios=20 metodol=F3gicos; no outro, n=E3o.

O PEP deve ser entendido n=E3o somente como a = informatiza=E7=E3o do=20 prontu=E1rio em papel, da mesma forma, ele n=E3o deve ser visto como um = produto que=20 se pode simplesmente comprar e instalar. Na verdade, o PEP =E9 um = processo, que=20 deve ser desenvolvido gradualmente, utilizando metodologias para um=20 desenvolvimento seguro e eficiente. Tal como qualquer sistema, o = desenvolvimento=20 de um PEP deve ser norteado segundo metodologias preconizadas pela = Engenharia de=20 Software (ES), que permitem uma perfeita organiza=E7=E3o do processo de=20 desenvolvimento, bem como um resultado final de alt=EDssima qualidade, = ou seja, um=20 software em perfeito acordo com seus requisitos.

O objetivo deste artigo =E9 assim descrever os = principais=20 m=E9todos, ferramentas e procedimentos na ES, destacando os seus = principais=20 aspectos, numa tentativa de oferecer uma vis=E3o geral sobre esta = =E1rea, para que=20 aqueles que estejam envolvidos no processo de desenvolvimento de um PEP, = possam=20 efetivamente utilizar este paradigma para a melhoria do processo e do = produto,=20 com benef=EDcios diretos para a institui=E7=E3o, seus usu=E1rios e = colaboradores.

ENGENHARIA DE SOFTWARE

Ainda que muitas defini=E7=F5es abrangentes tenham = sido propostas=20 para a ES, todas elas refor=E7am a exig=EAncia da disciplina de = engenharia no=20 desenvolvimento de software, e abrange um conjunto de tr=EAs elementos=20 fundamentais : m=E9todos, ferramentas e procedimentos. Onde os m=E9todos = detalham=20 "como fazer" para se construir o software, as ferramentas proporcionam = apoio=20 automatizado ou semi-automatizado aos m=E9todos, e os procedimentos = constituem o=20 elo de liga=E7=E3o que mant=E9m juntos os m=E9todos e as suas = ferramentas, e possibilita=20 um processo de desenvolvimento claro, eficiente, visando garantir ao=20 desenvolvedor e seus clientes, a produ=E7=E3o de um software de = qualidade=20 1.

Por que usar Engenharia de Software ?

Nos =FAltimos 20 anos, o hardware deixou de ser o = item mais caro=20 na implementa=E7=E3o de um sistema, enquanto que o custo relacionado ao = software=20 cresceu e se tornou o principal =EDtem no or=E7amento da computa=E7=E3o. = Isso se deve=20 principalmente pela crescente complexidade dos problemas a serem = resolvidos=20 pelos softwares. Sistemas como os de gest=E3o hospitalar e sistemas de = PEP chegam=20 a possuir milh=F5es de linhas de c=F3digo e envolvem v=E1rios = especialistas para o seu=20 desenvolvimento 2. Aliado a=20 isso, alguns problemas inerentes ao processo de desenvolvimento de um = software=20 come=E7aram a surgir 1 : as=20 estimativas de prazo e de custo freq=FCentemente s=E3o imprecisas, a = produtividade=20 das pessoas da =E1rea de software n=E3o tem acompanhado a demanda por = seus servi=E7os=20 e, a qualidade de software =E0s vezes =E9 menos que adequada, ocorrendo = muito=20 freq=FCentemente a insatisfa=E7=E3o do usu=E1rio. A chave para se vencer = esses problemas=20 e dificuldades acima relatados =E9 a larga utiliza=E7=E3o de uma = abordagem de=20 engenharia ao desenvolvimento de software, aliada a uma cont=EDnua = melhoria das=20 t=E9cnicas e ferramentas 1, = 2,=20 no intuito tamb=E9m de melhorar a produtividade da equipe = 2.

Dessa forma, podemos destarcar duas tend=EAncias para = justificar=20 o uso da ES : primeiro, o software =E9 um item de alto custo e em = progressivo=20 aumento; e segundo, que os softwares t=EAm um importante papel no = bem-estar da=20 sociedade 3; = dessa forma, a=20 ES assume papel cr=EDtico para garantir que tarefas, dados, pessoas e = tecnologia=20 estejam apropriadamente alinhadas para produzir um sistema efetivo e = eficiente=20 4.

PARADIGMAS DA

ENGENHARIA DE SOFTWARE

Um conjunto de etapas s=E3o definidas no processo de=20 desenvolvimento de um software, a esse conjunto de etapas denomina-se de = Paradigmas da ES 1.

Destacam-se 4 paradigmas principais 1,=20 5: o ciclo de vida cl=E1ssico , a = prototipa=E7=E3o, o=20 modelo espiral e as t=E9cnicas de Quarta gera=E7=E3o (4GT). Deve ser = lembrado=20 ainda, que podemos combinar os paradigmas, obtendo-se um melhor = resultado.

Figura 1 - Ciclo de vida cl=E1ssico

Independentemente do paradigma a ser utilizado, 3 = fases=20 gen=E9ricas dividem o processo de desenvolvimento 1 : Defini=E7=E3o. Esta fase = focaliza o=20 "o qu=EA" (an=E1lise do sistema, planejamento do projeto de = software e=20 an=E1lise de requisitos). Desenvolvimento. Focaliza-se o = "como"=20 (projeto de software, codifica=E7=E3o e realiza=E7=E3o de testes do = software).=20 Manuten=E7=E3o. Concentra-se nas "mudan=E7as" = (corre=E7=E3o, adapta=E7=E3o e=20 melhoramento funcional).

A Prototipa=E7=E3o traz bons resultados = principalmente=20 quando o cliente n=E3o tem precis=E3o na declara=E7=E3o do problema. A = constru=E7=E3o de=20 prot=F3tipos em projeto de PEP deve ser extensamente utilizada, = principalmente=20 porque estes s=E3o sistemas complexos, que necessitam de um alto n=EDvel = de=20 colabora=E7=E3o do usu=E1rio no processo de desenvolvimento = 6.

O modelo espiral =E9 baseado no princ=EDpio do = desenvolvimento=20 incremental, onde novas fun=E7=F5es s=E3o adicionadas a cada ciclo. = An=E1lise,=20 especifica=E7=E3o, projeto, implementa=E7=E3o e valida=E7=E3o s=E3o = repetidas a cada ciclo,=20 gerando uma nova vers=E3o do software e permitindo um feedback mais = imediato do=20 usu=E1rio 2.

As t=E9cnicas de quarta gera=E7=E3o utilizam = poderosas ferramentas=20 para o desenvolvimento do software, essas permitem um n=EDvel de = especifica=E7=E3o=20 mais elevado, pr=F3ximo =E0 linguagem natural, sendo capazes =E0 partir = dessas=20 defini=E7=F5es, gerar o c=F3digo-fonte do sistema 1.

GERENCIAMENTO DE PROJETOS

O gerenciamento de projetos abrange todo o = desenvolvimento,=20 sendo praticado em cada etapa do processo. Uma das primeiras atividades = de=20 gerenciamento =E9 o chamado Estudo de Viabilidade. Sua proposta = =E9=20 justificar a necessidade para o desenvolvimento do sistema, tanto do = ponto de=20 vista t=E9cnico e organizacional como financeiro (custos), atrav=E9s do = estudo de=20 =EDndices como Retorno sobre Investimento 7. No gerenciamento, deve-se = destacar o uso das=20 m=E9tricas de software que s=E3o usadas para medir a qualidade = dos softwares=20 e controlar a produtividade dos projetos 5. As m=E9tricas podem ser = categorizadas como=20 diretas ou indiretas; da produtividade, da qualidade e t=E9cnicas; e = ainda em=20 orientadas ao tamanho (LOC), =E0 fun=E7=E3o (FP - Function Point) e =E0s = pessoas=20 8.

O planejamento, como atividade de gerenciamento, deve = ocorrer=20 baseado em estimativas seguras, e em geral, estas possuem a = experi=EAncia=20 passada como =FAnico guia. Da=ED surge a necessidade de efetivamente = usarmos=20 m=E9tricas de software, para construirmos uma grande base de = informa=E7=F5es, para que=20 possam ser utilizadas em projetos futuros. Diversos modelos emp=EDricos = de=20 estimativa foram desenvolvidos, destaca-se o COnstructive COst MOdel = (COCOMO)=20 3 e o modelo de = estimativa de=20 Putnam. H=E1 tamb=E9m modelos de gr=E1ficos para o controle do = cronograma do projeto,=20 tais como o de Gantt e o PERT 4 .

O n=FAmero de artigos que tratam de gerenciamento de = projeto, em=20 assuntos como m=E9tricas, estimativas, an=E1lise de riscos, dentro de um = projeto de=20 PEP s=E3o extremamente escassos. Acredita-se que isso seja por falta de=20 publica=E7=E3o, mas se pode tamb=E9m imaginar que seja por = desconhecimento dessas=20 t=E9cnicas, ou que elas sejam, simplesmente, ignoradas.

AN=C1LISE DE REQUISITOS e

ESPECIFICA=C7=C3O

Os requisitos referem-se =E0s necessidades dos = usu=E1rios. =C9 de=20 fundamental import=E2ncia a compreens=E3o total dos requisitos dos = software para se=20 obter sucesso no desenvolvimento de softwares 1,=20 5. A an=E1lise de requisitos visa tamb=E9m = garantir uma=20 estrutura de dados adequada, para que futuras aplica=E7=F5es, tais como = estudos de=20 resultados cl=EDnicos, possam ser implementados e contar com todas as = informa=E7=F5es=20 necess=E1rias 9. = A=20 especifica=E7=E3o =E9 de suma import=E2ncia, pois a maior parte dos = erros encontrados=20 durante os testes e a opera=E7=E3o dos sistemas s=E3o derivados de um = pouco=20 entendimento ou m=E1 interpreta=E7=E3o dos requisitos 5,=20 2.

Existem diversas t=E9cnicas para an=E1lise e = modelagem de sistemas,=20 tais como : an=E1lise estruturada, an=E1lise orientada a objeto (OOA), = modelagem de=20 dados, dentre outras. Atualmente destaca-se a OOA que introduziu uma = s=E9rie de=20 novos conceitos. A OOA traz v=E1rios benef=EDcios, tais como : = funcionalidades=20 complexas podem ser desenvolvidas com uma codifica=E7=E3o menor e = melhor; um r=E1pido=20 desenvolvimento =E9 alcan=E7ado comparado a outros m=E9todos e as = aplica=E7=F5es s=E3o=20 mantidas mais facilmente 7.

Com a evolu=E7=E3o dos processos, sentiu-se a = necessidade de se ter=20 uma linguagem unificada que se tornasse poderosa o suficiente para = modelar=20 qualquer tipo de aplica=E7=E3o. Dessa necessidade, surgiu a UML (Unified = Modeling=20 Language), uma linguagem padr=E3o para especificar, visualizar, = documentar e=20 construir artefatos de um sistema. Grandes grupos tais como o OMG = (Object=20 Management Group) aprovam e est=E3o envolvidos no processo de = normatiza=E7=E3o desta=20 linguagem 10. =

Hoje, a maioria dos sistemas de PEP utilizaram ou = utilizam a=20 OOA, com v=E1rios trabalhos descrevendo o uso da OOA em PEPs = 11, 12.

PROJETO e IMPLEMENTA=C7=C3O

Enquanto as especifica=E7=F5es concentram-se no "o = qu=EA" a solu=E7=E3o=20 far=E1, o projeto descreve "como" o software ser=E1 implementado = 8. =C9 durante a fase de projeto = que a estrutura=20 geral e o estilo s=E3o definidos 13. Segundo Pressman 1,=20 1995, essa fase do desenvolvimento, produz : um projeto de dados, um = projeto=20 arquitetural e um projeto procedimental.

Al=E9m desses um projeto de interface distinto deve = ser=20 elaborado, que estabelece o layout e os mecanismos para intera=E7=E3o = homem-m=E1quina=20 1. Estudos tem = demonstrado=20 que at=E9 75% de todo o c=F3digo da aplica=E7=E3o =E9 destinada a = interface, tamanha a sua=20 import=E2ncia 2. = O estudo da=20 interface com o usu=E1rio =E9 de fundamental import=E2ncia no = desenvolvimento de PEPs,=20 onde uma intera=E7=E3o adequada =E9 necess=E1ria para ades=E3o dos = usu=E1rios ao sistema;=20 assim, conceitos como usabilidade e ergonomia, bem como uma s=E9rie de=20 recomenda=E7=F5es para a interface, tornam-se importantes para garantir = o sucesso de=20 um sistema de PEP 14, 15.. O=20 ideal =E9 que a interface seja intuitiva, f=E1cil de usar e acess=EDvel = para os=20 n=E3o-especialistas; para PEPs a interface deve ser adaptada ao m=E9todo = de trabalho=20 dos profissionais de sa=FAde, e ainda ser capaz de representar os = diversos tipos=20 de m=EDdia representes na informa=E7=E3o m=E9dica (texto, gr=E1ficos, = imagens e sons)=20 2.

Da mesma forma que na an=E1lise, existem diversos = m=E9todos para o=20 projeto do software, cada qual com o seu conjunto de princ=EDpios e = nota=E7=F5es.=20 Dentre v=E1rios podemos citar : projeto orientado ao fluxo de dados, = projeto=20 orientado a objeto (OOD), projeto estruturado e o desenvolvimento = estruturado de=20 Jackson. Entretanto, o OOD atualmente tem tomado a aten=E7=E3o dos = desenvolvedores,=20 que o t=EAm utilizado largamente, e em conjunto, obviamente, com a OOA,=20 constituindo uma metodologia completa : a an=E1lise e projeto orientado = a objeto=20 (OOAD). V=E1rios trabalhos citam o desenvolvimento de PEP utilizando = projeto=20 orientado a objeto 11, 12.=20 Com o OOAD =E9 poss=EDvel ainda a cria=E7=E3o de Design Patterns e = Frameworks. Design=20 Patterns s=E3o estruturas que aparecem repetidamente nos projetos = orientados a=20 objeto para resolver um determinado problema de forma flex=EDvel e = adapt=E1vel=20 dinamicamente, trazendo vantagens como : aumento da produtividade e da=20 consist=EAncia das aplica=E7=F5es, podem ser combinados para resolverem = problemas mais=20 complicados e, a cada dia, surgem novos padr=F5es que enriquecem o leque = de op=E7=F5es=20 para o desenvolvedor. Um Framework pode ser considerado como uma = infra-estrutura=20 de classes que prov=EAem o comportamento necess=E1rio para implementar = aplica=E7=F5es=20 dentro de um dom=EDnio espec=EDfico, funcionando com um molde para as = aplica=E7=F5es=20 16. Espera-se que = no futuro,=20 possa se contar com um grande n=FAmero de Design Patterns e Frameworks = para a=20 constru=E7=E3o de PEPs, e que aqueles que o desenvolverem compartilhem = com toda a=20 comunidade de desenvolvedores.

Ap=F3s o projeto, segue-se a codifica=E7=E3o, = tamb=E9m chamada=20 de implementa=E7=E3o. Esta fase =E9 uma simples quest=E3o de = tradu=E7=E3o do projeto para um=20 c=F3digo, j=E1 que as decis=F5es mais dif=EDceis j=E1 foram tomadas = durante a fase de=20 projeto 13. Temos = hoje as=20 ferramentas RAD (Rapid Application Development) que permitem ao = usu=E1rio um=20 r=E1pido desenvolvimento, baseado em conceitos de reusabilidade e = componentiza=E7=E3o.=20 Java, Visual Basic, Delphi e C++ s=E3o algumas das linguagens de = programa=E7=E3o mais=20 usadas atualmente. Al=E9m disso, tecnologias para o desenvolvimento de = sistemas na=20 Web tem tido um crescimento exponencial.

TESTE DE SOFTWARE

V=E1rias estrat=E9gias de testes podem ser = implementadas para=20 assegurar que o software est=E1 realmente em acordo com suas = especifica=E7=F5es e=20 livre de erros. Teste de unidade, teste de integra=E7=E3o, teste de = sistema, teste=20 de instala=E7=E3o e teste de aceita=E7=E3o s=E3o exemplos de t=E9cnicas = que podem ser=20 utilizadas 8. = Temos ainda o=20 chamado alfa-test onde o software =E9 testado num ambiente = controlado por=20 alguns usu=E1rios e na presen=E7a dos desenvolvedores; e o = beta-test, onde o=20 software =E9 testado por um conjunto maior de usu=E1rios, que se = prop=F5e a dar um=20 feedback aos desenvolvedores caso alguma irregularidade seja encontrada. = J=E1=20 existem ferramentas de software que automatizam o processo de teste. =

MANUTEN=C7=C3O

Em geral, a manuten=E7=E3o de software usualmente = consome mais que=20 60% do custo no ciclo de vida de um software, sendo isto devido ao fato = de que=20 os programadores, freq=FCentemente, s=E3o negligentes durante as fases = do=20 desenvolvimento do software, tais como an=E1lise e projeto = 5. Dessa forma, para uma = manuten=E7=E3o mais=20 tranq=FCila e segura, deve-se utilizar extensamente a ES que garantir=E1 = um design=20 adequado e escal=E1vel para futuras modifica=E7=F5es. Durante a = manuten=E7=E3o, s=E3o=20 realizadas atividades corretivas, adaptativas, perfectivas e = preventivas. A=20 manuten=E7=E3o de um sistema de PEP deve ser feita de maneira = criteriosa, para=20 evitar que altera=E7=F5es inseridas venham a prejudicar o funcionamento = do sistema e=20 incorra em erros que podem causar s=E9rios danos, principalmente ao = paciente, como=20 por exemplo, a disponbiliza=E7=E3o de informa=E7=F5es incorretas. =

QUALIDADE DO SOFTWARE

A ES =E9 a respons=E1vel pelo controle da qualidade = do software,=20 fazendo com que este atenda a todos os requisitos e atributos = 5, assumindo assim papel cr=EDtico = na produ=E7=E3o=20 dos sistemas. A garantia de qualidade de software (Software Quality = Assurance=20 =96 SQA) =E9 uma atividade que deve ser aplicada ao longo de todo o = processo de=20 ES; envolvendo revis=F5es t=E9cnicas formais, m=FAltiplas fases de = teste, controle da=20 documenta=E7=E3o de software e das mudan=E7as, um procedimento para = garantir a=20 adequa=E7=E3o aos padr=F5es e mecanismos de medi=E7=E3o e divulga=E7=E3o = 1.

A avalia=E7=E3o de um sistema de informa=E7=E3o = m=E9dico, como um PEP,=20 por exemplo, =E9 um processo que deve ser feito por toda a "vida" do = software,=20 devendo-se avaliar itens como : performance, custo-efetividade, = aceita=E7=E3o do=20 usu=E1rio e seguran=E7a 17.

Uma metodologia mais forte e organizada para a = avalia=E7=E3o da=20 qualidade que est=E1 em expans=E3o =E9 o CMM (Capability Maturity = Model), que=20 estabelece n=EDveis de maturidade no processo de desenvolvimento = 18.

FERRAMENTAS CASE

Nos =FAltimos anos, com a crescente complexidade das = metodologias=20 da ES, surgiram as ferramentas CASE (Computer-Aided Software = Engineering). Elas=20 ajudam o desenvolver em todo o processo de desenvolvimento, desde o=20 gerenciamento, an=E1lise, e algumas at=E9 mesmo na codifica=E7=E3o.

Entretanto, o uso dessas ferramentas ainda =E9 = pequeno,=20 principalmente nos projetos de PEP, como pode ser observado pela escassa = literatura sobre o assunto. =C9 importante se destacar que as = ferramentas CASE=20 aumentam a produtividade no desenvolvimento de grandes projetos de = sistemas de=20 informa=E7=E3o em sa=FAde 19. O=20 projeto HELIOS =E9 um excelente exemplo para um ambiente de ES para o=20 desenvolvimento de sistemas m=E9dicos, uma iniciativa que deve ser = seguida=20 20.

CONCLUS=C3O

O uso da ES =E9 uma tarefa dif=EDcil e extensa, = recheiada de=20 m=E9todos, que tornam sua utiliza=E7=E3o uma atividade para = especialistas. Entretanto,=20 n=E3o se deve relegar sua aplica=E7=E3o.

A import=E2ncia da computa=E7=E3o na sociedade = moderna tem aumentado=20 o significado do conceito de qualidade de software. Dessa forma, o=20 desenvolvimento de softwares =E9 hoje uma tarefa fundamental e, em = muitos casos,=20 de miss=E3o cr=EDtica.

Como vimos, para a constru=E7=E3o de softwares de = qualidade, uma=20 s=E9rie de etapas precisam ser seguidas. Um sistema de PEP precisa de = v=E1rios=20 passos para o seu desenvolvimento, com uma detalhada an=E1lise de = requisitos,=20 escolha de um modelo adequado, hardware e software para o aux=EDlio do=20 desenvolvimento, projeto de interface bem definido, os fatores humanos=20 considerados, fazer com que os usu=E1rios participem efetivamente do = processo de=20 desenvolvimento, para que tudo, em conjunto, produza um software de = qualidade,=20 confi=E1vel e, assim, obtenha sucesso.

Hoje, encontramos um panorama bastante preocupante no = desenvolvimento de sistemas de informa=E7=E3o em sa=FAde, e = principalmente sistemas de=20 PEP, pois a maioria das institui=E7=F5es e pessoas envolvidas no = processo, n=E3o est=E3o=20 utilizando nenhum dos paradigmas da ES, relegando um forte conjunto de=20 atividades que assegurariam a qualidade do produto. Isso tem = influ=EAncia direta=20 na qualidade da assist=EAncia =E0 sa=FAde dos pacientes : "softwares = ruins,=20 informa=E7=F5es ruins".

A busca para uma melhor assist=EAncia de sa=FAde e a = crescente=20 implementa=E7=E3o de PEPs tem gerado e ir=E1 gerar cada vez mais, uma = intensa demanda=20 por profissionais com habilidades em produzir software de qualidade, e = portanto,=20 com profundos conhecimentos em ES.

O intuito deste artigo foi assim, despertar a = comunidade de=20 desenvolvimento de sistemas de informa=E7=E3o em sa=FAde, ou seja, = m=E9dicos,=20 engenheiros, analistas, informatas em geral, para a ES. Procurou-se = oferecer um=20 breve panorama sobre como a disciplina deve ser aplicada, seus recursos, = paradigmas, m=E9todos, e principalmente, tentou-se demonstrar as = vantagens em se=20 utilizar a ES no processo de desenvolvimento de um sistema de PEP, = enfantizando=20 a melhoria da qualidade dos processos e produtos gerados, com o objetivo = final=20 de melhorar a qualidade da assist=EAncia =E0 sa=FAde prestada.

REFER=CANCIAS

  1. Pressman, R.S. Engenharia de Software. S=E3o Paulo : Makron Books, = 1995.

  2. Degoulet, P., Fieschi, M. Introduction to Clinical Informatics. = New York :=20 Springer-Verlag, 1997.

  3. Boehm, B.W. Software Engineering Economics. Englewood Cliffs :=20 Prentice-Hall, 1981.

  4. Murphy, G.F., Hanken, M.A., Waters, K.A. Electronic Health Records = :=20 Changing the Vision. Philadelphia : W.B. Saunders Company, 1999.

  5. Ramamoorthy, C.V., Prakash, A., Tsai, W.T., Usuda, Y. Software = Engineering=20 : problems and perspectives. Computer. Outubro 1984. P.191-209.=20

  6. Adelhard, K., Eckel, R., Holzel, D., Tretter, W. A prototype of a=20 computerized patient record. Comput Methods Programs Biomed 1995 = sep-oct;=20 48:115-9.

  7. Davis, M.W. Computerizing Healthcare Information : Developing = Electronic=20 Patient Information Systems. Revised edition. New York: Mcgraw-Hill, = 1998.

  8. Von Mayrhauser, A. Software Engineering: Methods and Management. = San Diego=20 : Academic Press, 1990.

  9. Dolin, R.H. Outcome analysis: considerations for an electronic = health=20 record. MD Comput 1997 jan-feb;14(1):50-6.

  10. Furlan, J.D. Modelagem de objetos atrav=E9s da UML. S=E3o Paulo : = Makron=20 Books, 1998.

  11. Egyhazy, C.J., Eyestone, S.M., Martino, J., Hodgson, C. = Object-oriented=20 analysis and design: a methodology for modeling the computer-based = patient=20 record. Top Health Inf Manage 1998 aug;19(1):48-65.

  12. Krol, M., Reich, D.L. Object-oriented analysis and design of a = health care=20 management information system. J Med Syst 1999 apr;23(2):145-58.

  13. Rumbaugh, J., Blaha, M., Premerlani et al. Modelagem e = projetos=20 baseados em objetos. Rio de Janeiro : Editora Campus, 1994.

  14. Sittig, D.F., Kuperman, G.J., Teich, J.M. WWW-based interfaces to = clinical=20 information systems: the state of the art. Proc Amia Annu Fall Symp=20 1996;:694-8.

  15. Ash, J.S. Factors affecting the diffusion of the computer-based = patient=20 record. Proc Amia Annu Fall Symp 1997;682-6.

  16. Apostila Orienta=E7=E3o a Objetos : Da teoria =E0 pr=E1tica em = Java.=20 CCUEC/Unicamp. (http://www.ccuec.unicamp.br).

  17. Perreault, L.E., Wiederhold, G. System Design and Evaluation. In : = Shortliffe, E.H., Fagan, L.M., eds. Medical Informatics : Computer=20 Applications in Health Care. New York : Addison-Wesley Publishing, = 1990.

  18. Software Engineering Institute - CMM (Capability Maturity Model) : = http://www.sei.cmu.edu.

  19. Lee, F.W. Can computer-aided systems engineering tools enhance the = development of health care information systems? A critical analysis. = Top=20 Health Inf Manage 1996 aug;17(1):1-11.

  20. Degoulet, P., Jean, F.C., Meinzer, H.P. et al. The HELIOS = medical=20 software engineering environment. Comput methods programs biomed 1994=20 oct;45(1-2):91-5.