Chapter 4: Empirical findings
4.3. Examples of combined ITT and CSR projects within Statoil
4.3.2. Skills-development and technology transfer programme in Venezuela
Ao desenvolver um SI para realizar t est es audiológicos foi possível perceber que ainda exist e m uit o t rabalho a desenvolver para adapt ar as TI a est a área da Saúde, para que possam ser subst it uídos os processos m anuais.
O desenvolvim ent o de um SI para a realização de t est es audiológicos int roduz um a m elhoria prát ica clínica na Audiologia, a falt a de soluções dest e género em Port ugal levou o GIBS a realizar est e t rabalho que se conclui com a versão act ual do sist em a apresent ada ao longo da dissert ação.
A m et odologia de desenvolviment o escolhida revelou-se a m ais adequada ao longo do processo pois perm it iu t est ar várias soluções dist int as e efect uar as correcções necessárias aos requisit os funcionais.
Os object ivos propost os inicialm ent e foram concret izados, os requisit os foram cum pridos e foi possível desenvolver um SI funcional.
Est e t rabalho foi um grande desafio pois foi necessário enquadrar várias t ecnologias diferent es no m esm o SI e fazer com que t odas com unicassem ent re si de form a segura sem int roduzirem erros na aplicação.
O SI desenvolvido encont ra-se num est ado de m at uração que perm it e a sua ut ilização para a realização de t est es cont udo o caract er vinculat ivo dos m esm os não deve ser levado em linha de cont a pois o sof t w are em quest ão não foi sujeit o a nenhum a avaliação de desem penho e de qualidade que perm it a garant ir a qualidade do t est e audiológico.
Recorrendo à t erm inologia ut ilizada pela IBM nos anos 50 para classificar o est ado de m at uração dos seus produt os, e que se est endeu a t oda a indúst ria de soft w are a versão act ual encont ra-se em Pré-alpha. (Pat t on, 2005)
Significa que t odas que as act ividades de análise de requisit os, desenvolvim ent o de soft w are e t est e dos com ponent es desenvolvidos foram concluídas, est ado pr ont o para se subm et er a um a bat eria int ensiva de t est es que possa ident ificar as falhas para que a aplicação possa chegar à fase Alpha.
O passo seguint e e que se enquadra nos desenvolvim ent os fut uros dest e project o é iniciar a validação do cont eúdo produzido at ravés de t est es de caixa branca e caixa pret a.
Os t est es de caixa branca focam -se no código font e da aplicação e são orient ados à lógica pret endem avaliar o fluxo de dados, condições lógicas, ciclos e encont rar código font e que devido a lógica errada nunca é execut ado. (Pat t on, 2005)
Para ut ilização dest a t écnica poderá ser ut ilizada a ferram ent a grat uit a JUnit que perm it e desenvolver cenários de t est e, para avaliar o código font e produzido em Java. (JUnit , 2013)
61 Os t est es de caixa pret a avaliam o com port am ent o ext erno do sist em a sem preocupação da form a com o est e foi im plement ado. Um exem plo t ípico dest e t est e é fornecer dados de ent rada à aplicação e com parar os result ados de saída com result ados previam ent e conhecidos, quant o m ais ent radas forem fornecidas e quant o m aior for o num ero de result ados conhecidos m ais eficaz será o t est e, sendo o cenário ideal t est ar t odas as com binações possíveis. (Pat t on, 2005)
O t est e de caixa pret a t em com o base os requisit os funcionais definidos na especificação inicial.
Concluídos est es t est es o sof t w are deverá at ingir o est ado bet a. Est a fase inicia-se quando t odos os requisit os est ão im plem ent ados e t est ados. O sof t w are em est ado bet a é soft w are ainda com anom alias e deverá ser sujeit o a um conjunt o de t est es que perm it a reduzir um possível im pact o negat ivo nos ut ilizadores.
Os t est es nest a fase são desenvolvidos por pessoas ext ernas ao project o e que pela sua act ividade virão a ser os ut ilizadores finais da aplicação.
Tipicam ent e nest es t est es são ident ificadas falhas a nível gráfico que dificult am ou im possibilit am a ut ilização do soft w are.
No caso especifico dest e sof t w are deverá ser dist ribuído a vários audiologist as a versão bet a da aplicação para que possa ser t est ada, junt am ent e com a aplicação deverão ser fornecidas as ferram ent as necessários para que event uais falhas possam ser report adas.
Após as correcções de event uais falhas det ect adas na fase bet a de t est es o Soft w are passará à versão RTM que significa release t o manufact uring, est a será a versão dest inada a um a ut ilização profissional.
Findos os t est es e at ingida a m at uridade necessária para um a ut ilização isent a de falhas deverá ser feit o o em pacot am ent o da solução e de t odos o soft w are ext erno que ut iliza, para que possa ser inst alada recorrendo a inst alador aut om át ico sem necessidade de configurações m anuais, no est ado act ual em que o soft w are se encont ra t odo o processo de inst alação é m anual. (Wright , 2011)
A Audiologia não se esgot a nos t ipos de t est es im plem ent ados nest e soft w are e a longo prazo o SI poderá ganhar m ais valor se forem adicionados novos t ipos de t est es audiológicos. Ant es dest a int rodução será im port ant e chegar a um a versão final das especificações act uais ant es da inclusão de novos recursos na aplicação por form a a evit ar que est a ent re em ciclo e nunca passe do est ado de bet a devido à necessidade const ant e de efect uar t est es de validação. Durant e o t em po de vida út il do SI deverá ser m ant ido o supor t e ao m esm o por form a a garant ir que t udo cont inua funcional e para efect uar as alt erações necessárias causadas pela evolução das TI.
Foi para m im m uit o grat ificant e e enriquecedor a realização dest e t rabalho, quer a nível de conhecim ent o ganho na área da Audiologia, quer a nível t écnico que m e perm it iu as capacidades de desenvolviment o em Java.
62 Rest a-m e concluir que m ant enho t oda a disponibilidade para ajudar a levar est e project o avant e, para que possa chegar a um a prim eira versão de produção que possa ser ut ilizada em t odo o país.
63