Identificação e Priorização de Requisitos

Os itens de demanda ergonômica (IDEs-Atividades) representam as atividades a serem informatizadas pelo projeto de software. Os itens de demanda ergonômica

(IDEs-Preocupações) representaram, nesta pesquisa, as preocupações relacionadas às atividades a serem informatizadas. As atividades, assim como as preocupações, compõe o conjunto de problemas a serem atendidos pelo software. Segue avaliação dos resultados identificados quanto aos IDEs.

4.3.3.1. IDEs-Atividades

No projeto Portofer haviam demandas não atendidas pelo projeto de software

(desenvolvido a partir da proposta técnica comercial) por diferentes motivos (Tabela 17):

a) demandas não identificadas: “Separação e controle de manobras realizadas com os vagões” e o “Controle de operações não permitidas - entrega de vagões fora do horário de trabalho do cliente”. Estas duas demandas foram identificadas pelo método DM mas não pela análise tradicional. Mesmo estas atividades não estando automatizadas, os operadores precisam continuar executando-as de qualquer maneira. Em um contexto real onde estas duas atividades se relacionam com 91,7 % das preocupações existentes no trabalho destes usuários;

b) demandas retiradas do escopo: as quatro atividades retiradas do escopo do software pelos gerentes refletiam, conforme identificado pelo método DM, em 50% das preocupações dos operadores: desta forma, o impacto da exclusão destas atividades pôde ser mensurado. Estas atividades, da mesma forma que as duas anteriores, tiveram de continuar sendo de total responsabilidade dos operadores, mesmo que não

informatizadas na implantação do sistema.

Tabela 17 - Lista dos IDEs-Atividades relacionados aos IDEs-Preocupações não atendidos ou retirados do escopo.

Ordem IDEs-Atividades Demandas

Não identificadas

Demandas Retiradas do

escopo

1 Melhorar atendimento ao cliente 9

2 Manter documentação/planilhas atualizadas 9 9

3 Agilizar a manobra de vagões 9

4 Manter a equipe instruída/acompanhada 9

5 Agilizar o caminho da ferrovia até o cliente 9

6 Atender corretamente os Terminais 9

7 Não permitir a ocorrência de acidentes no percurso

9 9

8 Fazer o controle operacional corretamente 9 9 9 Diminuir o tempo de permanência de vagões no

porto

9

10 Agilizar o atendimento operacional 9 9

11 Agilizar o retorno dos vagões p/ a ferrovia 9

12 Melhorar imagem da empresa 9 9

A metodologia tradicional é fundamentada em priorizações de requisitos de forma qualitativa. O método AMT/DM se baseia em priorizações quali-quantitativas destes requisitos. No projeto Portofer, uma relação priorizada de forma quantitativa poderia ter sido de grande valia para o analista de sistemas, o qual não conseguiu fundamentar suas preocupações em relação a redução do escopo. A priorização qualitativa se mostrou insuficiente.

Além da redução no escopo e prazo de desenvolvimento, o tempo disponível até a data

“escolhida” pelo cliente para a implantação do software somente permitia a implementação do módulo operacional. Devido a metodologia tradicional não viabilizar a mensuração da influência dos enfoques no contexto da organização, a resolução por parte do cliente por

desenvolver e implantar, num primeiro momento, somente o módulo operacional não pôde ter suas conseqüências avaliadas.

As atividades priorizadas quanto a sua importância refletem nos requisitos que demandam por soluções adequadas a um contexto de uso. O ideal é que as soluções desenvolvidas para cada uma das atividades fossem totalmente focadas na minimização das preocupações relacionadas a cada uma delas. Entretanto, segundo ABNT (2001), é praticamente

impossível garantir todas as características de qualidade para todas as partes de um produto de software de grande porte. Assim, a priorização das atividades em função das

preocupações relacionadas permite que a empresa invista mais esforços nos requisitos que devem receber maior atenção. No projeto Portofer, a maioria das preocupações são

relacionadas ao tempo de realização das atividades (“Agilizar ...”, “Diminuir ...”, etc.).

Consequentemente, no projeto Portofer, as atividades que devem ser priorizadas são as que, se mal feitas, irão gerar maior perda de tempo (interferindo na performance). Em outros projetos, o foco principal de preocupação pode ser relacionado a uma ou mais

características de qualidade, por exemplo, à segurança, a flexibilidade, a portabilidade, etc.

4.3.2.2. IDEs-Preocupações

A metodologia tradicional de identificação de requisitos não possui uma estratégia formal para identificação de preocupações que representem possíveis problemas para o projeto. Já a aplicação do método AMT/DM, feita nesta pesquisa, permitiu a identificação destas informações, o que vem a contribuir com a análise de riscos em projetos de software desde a fase de concepção.

A partir da identificação das preocupações, é possível gerar uma classificação. Esta classificação permite um enquadramento em tipos de fontes de problemas e viabiliza a minimização de problemas (como erros durante a operação do software). Segundo Woods et al. (1994), a ergonomia procura entender os fatores por trás do erro humano

considerando os problemas que as pessoas enfrentam e a organização que fornece os recursos para o trabalho e especifica seus objetivos.

A priorização dos IDEs-Preocupações apresenta quais as preocupações que ocorrem de forma mais freqüente durante a execução das atividades que fazem parte do trabalho dos usuários. Isto denota que as preocupações mais prioritárias são aquelas que ocorrem mais freqüentemente durante um ciclo completo de trabalho.

Para o projeto Portofer, o método AMT/DM gerou a importância dos três enfoques

(classificações): gerencial, atendimento a cliente e operacional. Esta importância não pôde ser mensurada com a identificação tradicional de requisitos. As preocupações com o

enfoque gerencial e com o atendimento ao cliente representam 81,1% das preocupações dos operadores, ou seja, é onde está a maior carga de concentração das suas atividades.

Durante a execução de suas atividades, os operadores do CCO focam seus esforços para evitar diferentes tipos de problemas: problemas relacionados ao atendimento aos clientes, problemas relacionados ao atendimento das solicitações dos gerentes e problemas

relacionados à qualidade com que as atividades operacionais devem ser executadas. Este conjunto de preocupações que pode conduzir os operadores a cometerem erros, é um sistema complexo sob o foco da ergonomia cognitiva (GUIMARÃES, 2001). Erros de decisão, segundo a ergonomia cognitiva, são erros mais difíceis de minimizar pois podem ser fruto da organização do trabalho mal concebida, fadiga, estresse, etc. É importante avaliar que as atividades essencialmente operacionais receberam maior prioridade, ao contrário das preocupações em função das atividades operacionais, que receberam menor prioridade.

Segundo Reason (1997), as pressões geradas em função do atendimento a uma determinada meta sem considerar os conflitos potenciais podem colocar os operadores em duplo

conflito. Nestas situações qualquer tentativa de atender a uma meta significa sacrificar o atendimento de outras metas conflitantes. Desta forma, os operadores são forçados a escolher uma situação menos danosa e, portanto, podem cometer algum erro. Este tipo de erro é apenas uma conseqüência de falhas organizacionais.

Sabendo-se que o papel do operador do CCO exige concentração, onde uma sobrecarga, estresse, fadiga, etc. pode resultar em erros de planejamento ou de controle e, por conseqüência, gerar um acidente de trabalho, certamente, justifica uma reorganização e nova priorização da visão que a gerência tem das atividades e das metas a serem atendidas pelos operadores do CCO. Sob o foco da ergonomia, é questionável desenvolver e

implantar um projeto de software para atender somente as preocupações sob um dos enfoques.

Para a engenharia de software, a implantação do módulo operacional, em sistemas de informação, antes do módulo de atendimento ao cliente e do módulo gerencial não é considerado errado e não é um procedimento raro. Entretanto, esta pesquisa permitiu observar que esta prática, quando o mesmo grupo de usuários possui preocupações em diferentes enfoques, pode refletir em conseqüências que inviabilizem a implantação do módulo.