From: 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
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