2.9 Critères des bases de données
2.9.6 Occultation
A figura 4.13 foca-se na utilização da TAXSI na ER. A TAXSI ajuda e facilita a compreensão do sistema em estudo permitindo que, após a sua utilização, os engenheiros de requisitos estejam muito mais informados para decidir o tipo de SIBC mais indicado para a situação em análise. O círculo na parte inferior da figura descreve o processo da ER como um processo iterativo composto por quatro tarefas: levantamento, validação/verificação, especificação/documentação e negociação (Pohl 1996). Pretende-se que a TAXSI seja particularmente útil numa fase inicial de levantamento de requisitos, podendo também dar um contributo para qualquer uma das outras fases, na medida em que todas estão interrelacionadas. Por exemplo, a elaboração da especificação de requisitos na fase de especificação/documentação recebe o input da fase de levantamento e eventualmente também da fase de negociação (por exemplo, a solução de um conflito ou a revisão de uma decisão anterior) (Pohl 1996).
A compreensão do sistema em estudo pode ser facilitada se se conhecer o domínio do negócio. Segundo Pohl (Pohl 1996) o conhecimento do domínio deve ser utilizado para guiar a fase de levantamento de requisitos. Este conhecimento implicitamente identifica os objectos que o constituem e os processos tipo. A TAXSI auxilia a identificação do domínio. Por outro lado, através da TAXSI é possível identificar para um dado processo qual a informação que irá ser manuseada pelos SIBC, e também o conhecimento que é necessário
ter sobre esse processo para construir um SIBC que o suporte. Este aspecto orienta de uma forma significativa o engenheiro de requisitos na sua tarefa de levantamento de requisitos. Por último, a identificação, através da TAXSI, dos tipos de SIBC que podem suportar um determinado processo, pode ou dar um ponto de partida para o desenho da arquitectura do sistema, ou orientar a aquisição de software.
Processos C o n h . O rg Levantamento Especificação/ Documentação Validação/ Verificação Negociação D1 D2 D3 Domínio Processos Conhecimento Organizacional SIBC DSS ERP CRM MIS EIS WMS EDI
Figura 4.13: Utilização da TAXSI na ER.
A utilização da TAXSI na ER envolve os seguintes passos:
1. Identificar o domínio do negócio, que, implicitamente, identifica os objectos que serão manipulados. Esta identificação pode ser feita recorrendo à tabela 4.12 – Domínio de negócio.
2. Identificar os processos relevantes. É importante definir o âmbito do desenvolvimento, o que pode ser feito recorrendo à tabela 4.7 – Descrição das tarefas associadas a cada processo.
3. Identificar o tipo de conhecimento que os processos manipulam, recorrendo às tabelas 4.13 – O conhecimento para os processos de gestão e suporte e 4.14 – O conhecimento para os processos primários. Neste caso as tabelas ajudarão a identificar:
• O tipo de conhecimento que os SIBC manusearão,
• O conhecimento que pode ser necessário para executar o processo, mas
que não é processado pelos SIBC,
• Onde se poderá obter esse conhecimento. As tabelas 4.13 e 4.14 não identificam directamente onde obter esse conhecimento. Contudo, em alguns casos (ambiente e pessoas) a partir do momento em que se identifica o conhecimento a obter, não é difícil descobrir onde o ir procurar.
4. Identificar que tipos de SIBC podem ser relevantes para a situação em causa, recorrendo à tabela 4.16 – O suporte dos SIBC aos processos/conhecimento.
Como exemplo de utilização da taxionomia, seguindo o método atrás delineado, considere-se uma empresa, por exemplo, uma Universidade, que pretende desenvolver um sistema para gestão dos recursos humanos.
Passo 1: Identificar o domínio do negócio: recorrendo à tabela 4.12 identifica-se o domínio Educação. O engenheiro de requisitos implicitamente reconhece que os principais objectos do sistema são alunos, professores, planos curriculares, etc.. A existência de uma ontologia neste domínio ajudaria o engenheiro de requisitos não só a identificar os objectos mas também as relações entre eles.
Passo 2: Identificar os processos: a consulta da tabela 4.7, indica o processo PG1 – Desenvolver e gerir recursos humanos. Daqui ressalta que é necessário analisar em particular como se faz a gestão do desempenho, recompensa e reconhecimento de funcionários, como se recruta, assalaria e forma funcionários, como se desenvolvem de planos de carreira e reforma, e como se estimam os custos de trabalho.
Passo 3: Identificar o tipo de conhecimento necessário para cada processo: Recorrendo à tabela 4.13 identifica-se o conhecimento que os SIBC manusearão (visão objecto/informação), e o conhecimento que pode ser necessário para executar o processo, mas que não estará nos SIBC (visão objecto/conhecimento). As duas primeiras linhas da
tabela 4.17 identificam que conhecimento é necessário levantar sobre os recursos humanos e sobre os processos que estará nos SIBC. As restantes linhas indicam que também é necessário levantar conhecimento sobre os recursos económicos, o ambiente geral, a finalidade e também sobre as pessoas, que tem influência no desenvolvimento e gestão dos recursos humanos, mas que não estará nos sistemas informáticos. Por exemplo, poderá ser necessário conhecer os recursos económicos para recrutar, assalariar e formar funcionários mas esse tipo de conhecimento pode não ser manuseado por um sistema que suporte essas tarefas.
Objecto Conhecimento
Recursos humanos Estrutura, habilitações académicas, salário
Processos Descrição, procedimentos, resultados, índices, regras
Índices de desempenho
Recursos Económicos Capital, custos e benefícios
Ambiente geral Legislação
Pessoas Cultura, capacidades, visão, comportamento, valores
Finalidade Objectivos
Tabela 4.17: Conhecimento necessário no exemplo.
Passo 4: Identificar que tipos de sistemas podem ser usados: a tabela 4.16 indica os sistemas possíveis:
Sistema de informação de recursos humanos (HRIS14) Sistema de planeamento dos recursos da empresa (ERP15)
Sistema de gestão de recursos assistido por computador (CAFM16) Sistema de processamento de dados administrativos
Sistema de gestão de fluxo de trabalho (WMS17)
Neste momento, será mais fácil decidir, de entre as alternativas sugeridas, qual o sistema a utilizar. Os engenheiros de requisitos estão agora muito mais informados sobre que tipo de suporte o novo sistema pode dar aos processos e ao conteúdo, ou seja, aos tipo de conhecimento. Para engenheiros de requisitos séniores este tipo de ferramenta não será tão relevante, pois grande parte deste conhecimento já foi interiorizado, mas é certamente uma
14
Human Resources Information System
15
Enterprise Resource Planning
16
Computer Aided Facility Management
17
ajuda para os mais júniores, ajudando-os a disciplinarem-se no próprio processo da ER e orientando-os num projecto específico.
Por outro lado, argumenta-se que uma ferramenta deste tipo tem uma grande relevância pedagógica na medida em que a utilização do método delineado em aulas de disciplinas que foquem o DSI, treina os alunos para uma forma sistemática de levantar requisitos.