Resumo—Este trabalho é composto por duas partes, uma
elaborada no programa Microsoft Project onde se faz a gestão de um projecto de desenvolvimento de um sistema de informação e outro com a ferramenta BiZagi para a gestão de um Processo de creditação de competências, neste caso o pedido de equivalências de um novo aluno de uma escola.
Palavras chave—Microsoft, Project, BPMN, BiZagi, gestão,
projecto, processos, negócio, sistemas, informação.
I. INTRODUÇÃO
STE trabalho tem duas partes distintas, uma referente a uma simulação de gestão de um projecto, outra de um processo de negócio.
O projecto em questão inicia-se a 19-12-11, o gestor decidiu que o projecto deve ser dividido em quatro fases.
No segundo pretende-se simular o pedido equivalências de um aluno a uma determinada escola, nesse processo, ele começa por enviar a documentação à escola. O funcionário dos serviços académicos, depois de validar a documentação, dá início ao processo de creditação de competências, nesta fase o coordenador do curso faz também uma avaliação do processo e, depois de validar, encaminha-o para os responsáveis das unidades curriculares que é necessário consultar. Após receber os pareceres o coordenador faz uma proposta e remete para a comissão científica que, por sua vez, elabora o parecer para ser enviado ao aluno e arquivado pelo funcionário dos serviços académicos.
Para elaborar este processo foi utilizada a ferramenta, sugerida pelo professor, BiZagi.
II. GESTÃO DE PROJECTO A. Concepção
Esta fase é levada a cabo pelo analista e engenheiro de sistemas, tem uma duração de 4 dias no total, tem como objectivo a recolha de informação referente ao projecto, define-se as necessidades e restrições. Engloba o
levantamento de Modelação do negocio, Levantamento de requisitos e analise e desenho global.
B. Implementação
Nesta fase cria-se o modelo do sistema a implementar, selecciona-se a linguagem de programação, define-se módulos a implementar, programa-se o sistema, efectua-se testes e por ultimo instala-se o sistema, tem uma duração total de 8 dias. Engloba instalação da plataforma de hardware, analise e desenho dos módulos principais e secundários, programação dos módulos, testes dos módulos, formação nos módulos principais, desenvolvimento dos relatórios
financeiros, implementação do sistema de informação. C. Manutenção
Esta é a fase final de implementação do projecto, tem uma duração de 1 dia e engloba as fases, formação avançada, contudo esta fase fica sempre em aberto com objectivo de rever certos bugs no sistema.
D. Recursos
Para desenvolvimento do sistema de informação estão disponíveis os seguintes recursos humanos, o analista Victor Baptista, e Engenheiro de Sistemas Bruno Gonçalves e os programadores João Caixinha e Pedro Moreira.
E. Atribuição de tarefas
Decidiu-se distribuir as tarefas pela equipa de trabalho como se pode verificar nos pontos seguintes e na figura 1.
Victor Batista
Modelação do negócio Levantamento de requisitos Análise e desenho global
Desenvolvimento dos relatórios financeiros
Trabalho de Grupo – Gestão de Projecto e
Gestão de Processos de Negócio
João Caixinha, 5946, Pedro Moreira, 10015, 2.º Ano (2011/2012)
João Caixinha
Análise e desenho detalhado dos módulos principais Programação dos módulos principais
Teste dos módulos principais Formação nos módulos principais Formação avançada
Pedro moreira
Análise e desenho detalhado dos módulos secundários Programação dos módulos secundários
Teste dos módulos secundários Bruno Gonçalves
Selecção da plataforma de hadware Aquisição do hardware
Instalação da plataforma de hadware Implementação do sistema de informação
Aparenta ser a forma mais lógica para lidar com o projecto e como se pode comprovar de forma gráfica no Microsoft Project, nenhum dos recursos esta subcarregado, sugerindo então que esta é eficiente.
F. Definir pagamentos
Definiu-se que que os intervenientes no projecto iriam ser remunerados da seguinte forma:
Analista- 14 euros/h e 4 euros/h por horas extra Eng. Sistemas- 15 euros/h e 5 euros/h por horas extra Programadores - 14 euros/h e 4 euros/h por horas extra Atribui-se ainda mais 10% ao técnico responsável pela tarefa formação avançada no dia 3-1-12 como se pode verificar na figura 4.
G. Definir horários de trabalho
Como se trata de um projecto urgente, admitiu-se que os técnicos irão trabalhar sábados e a empresa dará tolerância no dia 26 Dezembro precedente ao natal, pode-se comprovara na figura 5.
H. Conclusão
Estima-se que o tempo necessário para a execução do projecto são 14 dias úteis com um custo total de 2.912 euros comprovado através dos relatórios produzidos anteriormente pela aplicação.
III. GESTÃO DE PROCESSOS DE NEGÓCIO A. Process
Começámos por modelar o processo no BiZagi Process
Modeler “Fig. 6”. Dividimo-lo em três sub-partições – Pedido de Equivalências, Creditação de Competências e Parecer.
Os actores intervenientes são compostos pelo estudante, funcionário dos serviços académicos, coordenador do curso, responsáveis das unidades curriculares e comissão científica.
No Pedido de Equivalências o Estudante executa a tarefa Solicitar Equivalências que é precedida pela validação do pedido por parte do Funcionário dos Serviços Académicos. Aí entra-se num processo de decisão onde, caso rejeitado, dá origem à tarefa Pedido Rejeitado.
No caso de ser aceite entramos noutra sub-partição - Creditação de Competências. O Coordenador do Curso executa a tarefa Avaliação Preliminar, que por sua vez também dá origem a outro processo de decisão que, se negativo segue para o Pedido rejeitado, em caso contrário o fluxo é encaminhado para os Responsáveis das Unidades Curriculares com a tarefa Verificar Equivalências.
Terminada a verificação das equivalências entramos na última sub-partição – Parecer. O Coordenador termina a sua intervenção no processo com a tarefa Envio de Pareceres onde, após recebê-los todos, elabora uma proposta, entregando-a à Comissão Científica com a tarefa Elaborar Despacho de Equivalência.
Terminado o despacho, a última tarefa - Envio do Despacho ao aluno - cabe ao Funcionário dos Serviços Académicos que notifica o Estudante e dá por finalizado este Processo de Negócio.
B. Data
Identificámos como atributos do processo “Fig. 7” os anexos (do tipo file) cópia do Bilhete de Identidade e o Certificado de Habilitações, com o tipo de date a data do pedido e a Data do Despacho. Com o tipo string temos as Disciplinas aprovadas e o Despacho.
Para os processos de decisão foram definidos três atributos, do tipo boolean, Prosseguir com o pedido, Disciplina Aprovada e Documentação ok.
O Estudante foi adicionado à lista como WFUSER e, finalmente, um parâmetro do tipo Entidade – Motivos de Rejeição, por sua vez com um atributo – Motivo do tipo string, para ser apresentada a lista de motivos seleccionáveis para a rejeição do pedido.
C. Forms
São apresentados de seguida os campos utilizados nos formulários das respectivas tarefas:
Solicitar Equivalências. É utilizado um formulário com os campos não editáveis - Data do Pedido e Nome do aluno. Também tem como campos do tipo file, os Certificado de Habilitações e Cópia do Bilhete de Identidade.
Validar Pedido. O formulário construído contém os campos não editáveis - Data do Pedido, Nome do aluno, Certificado de Habilitações e Bilhete de Identidade. Para a validação é utilizado um campo do tipo boolean.
Validação Preliminar. Nesta tarefa o formulário é idêntico ao utilizado em Validar Pedido, apenas difere no campo boolean, pois trata-se de um atributo distinto.
Pedido Rejeitado. Todos os campos neste formulário são não editáveis, pois apenas serve para informar o estudante da rejeição do pedido. Os campos criados são: data do pedido, certificado de habilitações, cópia do bilhete de identidade e motivo da rejeição.
Verificar Equivalências. Também nesta tarefa o formulário segue as mesmas indicações do utilizado na tarefa Validar Pedido, o campo boolean é utilizado para a aprovação, ou não, da equivalência.
Envio de Pareceres. É utilizado um formulário com os campos não editáveis: data do pedido, nome do aluno, certificado de habilitações, bilhete de identidade, e o boolean com a disciplina aprovada, ou não. Há também um campo editável do tipo string onde são escritas todas as disciplinas aprovadas.
Elaborar Despacho de Equivalência. Nesta tarefa é apresentado um formulário com a data do despacho, data do pedido, nome do aluno, certificado de habilitações, cópia do bilhete de identidade, lista com as disciplinas aprovadas e como único campo editável o Despacho.
Também é acrescentada uma pequena mensagem a informar para se enviar a cópia para o aluno e arquivar o despacho. D. Business Rules
Neste trabalho há dois processos de decisão e neles estão criadas duas expressões para controlar a direcção do fluxo do processo. Em Validar o Pedido caso o campo Documentação ok tenha sido validado com falso é tomado o caminho para a tarefa Pedido Rejeitado, caso contrário Avaliação Preliminar. No outro processo de decisão, caso o campo Prosseguir com o pedido tenha disso validado com falso, segue também para a tarefa Pedido Rejeitado, caso contrário para Verificar Equivalências.
E. Activity Actions
Foram criadas duas acções, a primeira tarefa Solicitar Equivalências, onde é logo definida a data do pedido. A segunda acção ocorre em Elaborar Despacho de Equivalência, onde é também automaticamente definida desde logo a data do despacho.
F. Aplicação WEB
Na aplicação WEB foram criados 5 utilizadores com os logins – aluno, acad, coordenador, curricular e cientifica, todos eles no mesmo domínio – fsi e com as passwords iguais aos login.
Em Entidades nos Motivos de Rejeição, foram adicionadas as opções: “Documentação incompleta”, “Bilhete de Identidade não válido”, “Certificado de Habilitações não válido”, “Aluno não elegível para um processo de creditação de competências” e “Outros motivos. Deve contactar os serviços académicos”.
G. Conclusão
O trabalho está completo, foi testado e funciona correctamente, são apresentadas como apêndices algumas visualizações das variadas etapas do processo.
Gestão de Projecto
Fig. 1. Atribuição de Tarefas
Fig. 2. Orçamento
Fig. 3. Orçamento
Gestão de Processos de Negócio
Fig. 6. Diagrama elaborado no BiZagi Process Modeler
Fig. 8. Início do Processo com o login: “aluno”
Fig. 10. Validação do pedido (Avaliação preliminar) com o login “coordenador”
Fig. 12. Envio de parecer para a comissão científica com o login “coordenador”
