Processo de análise e validação

Na fase inicial do projecto foram estabelecidas algumas metas que com o decorrer da fase de análise se foram alterando. No início do projecto foi definido como objectivo o desenvolvimento de três componentes: o módulo de agendamento de protocolos; o algoritmo de agendamento e o módulo de gestão de conflitos.

No decorrer do projecto, e tendo em conta as prioridades definidas pelo cliente, a lista de objectivos alterou-se. O algoritmo de agendamento de protocolos foi colocado em segundo plano, uma vez que a empresa já tinha uma solução testada. A solução existente não cumpre todos os requisitos estabelecidos, no entanto, consegue responder aos mínimos exigidos.

Entende-se por mínimos a capacidade do algoritmo fornecer um conjunto de vagas que respeitem as restrições, sem ter de se preocupar com questões de optimização. Pretende-se que no futuro em vez de construir um algoritmo de agendamento de raiz, seja melhorado o existente. Para esse efeito já existe um plano que define as características a melhorar. Entre estas características, a mais relevante diz respeito à necessidade de obter soluções que optimizem um determinado critério (diminuição do tempo de espera do paciente ou aumento da taxa de ocupação dos recursos).

Para além da componente relativa ao algoritmo de agendamento, também os outros dois módulos sofreram uma reestruturação completa. Para facilitar a compreensão da dimensão das alterações, é apresentada uma pequena descrição destes dois módulos, no início do projecto e na fase actual (perspectivando-se mais alterações no futuro).

Início do Projecto

 Módulo de agendamento – o módulo de agendamento deve permitir especificar um conjunto de características fundamentais para o processo de agendamento de um protocolo. A principal característica é o tempo. Antes de o médico executar a acção de agendamento, deve estipular a data, ou o período temporal, que pretende para a marcação. Caso o módulo não consiga encontrar uma solução com as restrições definidas, então o médico tem duas opções: ou redefinir as características e voltar a tentar a marcação, ou forçar a marcação e enviar um pedido para o módulo de gestão de conflitos.

 Módulo de gestão de conflitos – O módulo de gestão de conflitos recebe todos os pedidos de agendamento que não foram resolvidos numa primeira instância pelo módulo de agendamento. O módulo disponibiliza uma listagem de todos os protocolos em lista de espera e permita efectuar a sua marcação individual. Para cada um dos módulos, o utilizador, neste caso os Administrativos ou os enfermeiros, deve proceder à marcação do protocolo de forma manual. O utilizador deverá ter acesso a um ecrã onde é possível verificar as actividades do protocolo e as vagas disponíveis. Esse mesmo ecrã deve permitir estabelecer a associação entre os elementos, concretizando assim o agendamento. Caso o sistema indique que não existem vagas para uma determinada actividade, o utilizador dever ter o poder de forçar a sua marcação, ficando esta à sua responsabilidade.

Fase actual do projecto

 Módulo de agendamento – o módulo de agendamento de protocolos passou a designar-se módulo de prescrição e agendamento de protocolos. O módulo passou a ter a responsabilidade de prescrever e depois agendar um novo protocolo a um paciente. Este facto alterou radicalmente a lógica de negócio, já que agora é necessário efectuar todos os mecanismos necessários para prescrever um protocolo e validar a sua atribuição. A prescrição de um protocolo subentende a selecção de um paciente e depois a escolha de um protocolo. Uma vez escolhido o protocolo é necessário preencher um conjunto de características que o caracterizam, como por exemplo: a data pretendida para agendamento; o posto de tratamento e o contexto do doente. Antes de ser possível

agendar um protocolo é necessário validar um conjunto de critérios, que permitam verificar se o paciente está apto para ser submetido ao protocolo. A validação existe por questões de segurança e permite alertar para possíveis falhas técnicas, como por exemplo, o médico não reparar que o paciente é alérgico a determinada substância. Quando todos os detalhes referidos anteriormente estiverem devidamente concluídos, então o médico pode finalmente requisitar a marcação do protocolo. A partir desta fase o módulo segue um comportamento análogo ao definido na fase inicial.

 Módulos de gestão de conflitos – também neste módulo ocorreram alterações significativas a nível conceptual. O módulo passou de um simples componente de resolução de conflitos, para um componente em que é possível também marcar e alterar os restantes ciclos de um protocolo. Resumindo, o módulo de gestão de conflitos passou a ser o centro das marcações, sendo agora conhecido por Módulo de marcação. Uma vez feito o agendamento do período inicial do protocolo (que pode ocorrer neste ou no módulo anterior), todos os restantes ciclos serão marcados neste módulo. Assim sendo, este módulo ganha outro relevo, já que se torna numa aplicação central no contexto hospitalar. O ecrã inicial do módulo contém todos os protocolos em lista de espera, quer por estarem em estado pendente, como à espera da marcação dos ciclos sucessivos. Depois de escolhido um protocolo é apresentado um ecrã de marcação similar ao descrito na fase inicial.

Um conceito importante que foi introduzido no decorrer do projecto é a noção de tarefa mestre. Cada um dos protocolos tem à partida definida uma tarefa mestre que condiciona toda a marcação de um protocolo. Uma vez encontrada disponibilidade para marcar a tarefa mestra, todas as outras são marcadas, mesmo que para isso seja necessário forçar a sua marcação. Este conceito foi introduzido porque normalmente num protocolo existe uma tarefa que necessita de um conjunto de recursos mais escassos, logo, a prioridade é agendá-la.

Técnicas usadas para identificar e validar os requisitos

Muitas vezes a troca de ideias com o cliente é difícil sendo necessário utilizar um conjunto de ferramentas que as permitam esclarecer. Nesse âmbito foi adoptada a construção de protótipos. Os protótipos numa primeira fase são deita-fora e depois evolutivos. A negociação com o cliente foi morosa e conduziu a uma panóplia de protótipos (D ). Embora a construção de protótipos implique gastar muito tempo e congelar a evolução do produto, mostrou ser a única forma eficaz de conseguir levar o projecto a bom porto.

A etapa de prototipagem foi composta por duas fases distintas: os protótipos deita-fora, e os protótipos evolutivos [Som04]. Os protótipos deita-fora não são funcionais, mas apenas ilustrativos, normalmente são concretizados em papel ou num formato de apresentação (por exemplo power point). Os protótipos evolutivos são funcionais e pretendem reaproveitar todo o esforço realizado, podendo ser aproveitados para o desenvolvimento da aplicação.

Numa primeira fase foram validados os conceitos mais gerais da aplicação, como as funcionalidades a inserir, o ciclo de funcionamento da aplicação, a composição das interfaces e alguns detalhes de usabilidade do produto. Na segunda fase foram validados exaustivamente os detalhes definidos na primeira, verificando assim se estavam realmente em concordância com o

pretendido. Para além disso também foram aprofundadas as questões de usabilidade da aplicação. O cliente foi convidado a interagir com o protótipo e a criticá-lo, estabelecendo assim um elo de ligação com o projecto, fazendo-o sentir parte integrante. O facto de o cliente estar embrenhado no projecto é um factor importante para o seu sucesso, porque diminui a probabilidade de haver alterações de última hora. O cliente tem conhecimento das últimas evoluções e no extremo poderá ser um dos seus principais impulsionadores e defensores.

Para além da prototipagem também foram utilizados nesta fase de análise e validação de requisitos os convencionais diagramas de casos de uso, que permitem documentar de forma eficaz e clara o que ficou acordado com o cliente.