SCOS - Sistema de Controle de Ordens de Serviço



S.C.O.S

(Sistema de Controle de Ordens de Serviço)

Douglas da Silva Vilas Boas¹

Edson Rotatori Viana²

Marcos Antônio Sanches³

 

 

ABSTRACT

This work aims to develop a system for control Opening Orders for Enterprise SIMP (PAPER MACHINERY AND SYSTEMS LTD). The system was called SCOS (CONTROL SYSTEM SERVICE ORDERS) and was developed with the application of concepts in UML diagrams for modeling, also addressing the usability of the system, SQL Database, and Visual Basic programming language (in its version . net). This work was structured by processes of RUP methodology. The interface was created that add the greatest qualities is the routine process of the Technical Department of the Company providing tools that did not favor the old system. The final project proposal was presented to the company SIMP, which evaluated the interfaces and expressed its interest in the system.

 

Keywords: SIMP, SCOS, SQL, UML, Visual Basic, RUP;

 

RESUMO

Este Trabalho tem como objetivo desenvolvimento de um sistema para Controlar Abertura de Ordens de Serviço para a Empresa SIMP (SISTEMAS MÁQUINAS E PAPEIS LTDA). O Sistema foi intitulado S.C.O.S (SISTEMA DE CONTROLE DE ORDENS DE SERVIÇO) e foi desenvolvido com a aplicação de conceitos em UML para modelagem dos Diagramas, abordando também a usabilidade do Sistema, Banco de Dados SQL e Linguagem de programação Visual Basic (em sua versão .net). Este trabalho foi estruturado através da metodologia dos Processos RUP. A Interface que foi criada vem agregar maiores qualidades a rotina de processo do Departamento Técnico da Empresa proporcionando ferramentas que o antigo sistema não favorecia. A proposta do projeto final foi apresentado à empresa SIMP, que avaliou as interfaces e manifestou-se interessada pelo sistema.

 

Palavras-chave: SIMP, SCOS, SQL, UML, VISUAL BASIC, RUP;

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

¹ Analista de Negócios

Tecnólogo em Analise e Desenvolvimento de Sistemas

Veris Faculdades

E-mail: [email protected]

 

² Analista SGBD

Tecnólogo em Analise e Desenvolvimento de Sistemas

Veris Faculdades

E-mail: [email protected]

 

³ Analista de Sistemas

Tecnólogo em Analise e Desenvolvimento de Sistemas

Veris Faculdades

 E-mail: [email protected]

 

 

 

 

 

 

  1. Introdução

A SIMP SISTEMAS, MÁQUINAS E PAPÉIS LTDA, é uma empresa que apresenta ao público soluções em equipamentos multifuncionais como fotocopiadoras para escritório e/ou indústrias. Ela atua na comercialização desses equipamentos, Outsourcing e manutenção preventiva e corretiva são alguns dos serviços oferecidos. A empresa mantém laboratório próprio e equipe técnica permanentemente treinada e capacitada, para instalação e manutenção de equipamentos em todo o Vale do Paraíba, Região Serrana e Litoral Norte.

Partindo deste propósito o projeto do sistema que será apresentado neste artigo aborda deficiências que existem no atual software em funcionamento, oferecendo a possibilidade de gerenciamento de ordens de serviço, de clientes, de equipamentos, gerenciamento de estoque e relatório das ordens de serviço.

A motivação para o sistema deu se através de reclamações dos próprios funcionários do departamento técnico e clientes da Empresa SIMP, onde os mesmos informam que o atual sistema não oferece um gerenciamento de ordens de serviço e elaboração de relatórios para avaliação técnica

Devido este fato foi proposta a empresa a criação de um sistema que mantivesse as funcionalidades de cadastros de clientes e equipamentos, porém foram solicitados novos requisitos quanto as Ordens de Serviço, além de novas funcionalidades no setor de estoque e elaboração de relatórios de ordens de serviço.

 

 

 

 

  1. Desenvolvimento

Este Capítulo apresenta as bases teóricas utilizadas no desenvolvimento do projeto e toda estrutura de pesquisa realizada.

2.1  Engenharia de Software

Engenharia de Software: abrange um conjunto de três elementos fundamentais – métodos, ferramentas e procedimentos – que possibilita ao gerente o controle do processo de desenvolvimento do software e oferece ao profissional uma base para a construção de software de alta qualidade produtivamente.

(PRESSMAN, 2005)

Dentro deste contexto de desenvolvimento de software, a união dos métodos, ferramentas e procedimentos constituem o que se pode chamar de Paradigma de Software.

2.2  Modelo Processo Unificado – RUP

O Processo Unificado (doravante RUP) é um processo genérico, orientado por casos de uso,  que trabalha com arquitetura centrada, desenvolvimento iterativo e incremental, além de possuir 4 fases e 5 workflows (disciplinas), além disso ele pode ser customizado acrescentando ou removendo atividades de acordo com as necessidades do projeto.

Segundo Scott (2003), é importante lembrar, também, que o RUP está diretamente ligado a UML, uma vez que seus principais criadores Ivar Jacobson, Grady Booch e Jim Rumbaugh são os mesmos desenvolvedores da UML.

A seguir são descritas as principais vantagens do RUP.

  • Dirigido por Casos de Uso: um caso de uso é uma sequência de ações, executadas, por um ou mais atores e pelo próprio sistema, com a função de retornar um ou mais resultados para um ou mais atores. Um dos aspectos mais importantes do RUP é o emprego de casos de uso na condução do desenvolvimento, sendo estes utilizados para dirigir todo o desenvolvimento, desde a captação inicial de requisitos até a aceitação do código. (SCOTT, 2003)
  • Centrado em Arquitetura: O RUP especifica que a arquitetura do sistema em construção deve ser uma das principais preocupações da equipe do projeto, uma vez que, em conjunto com os casos de uso deve orientar para a exploração de todos os aspectos do sistema, fornecendo uma visão global do projeto como um todo e destacando suas características mais importantes (SCOTT, 2003)
  • Iterativo e Incremental: Segundo Scott (2003), uma iteração é um mini-projeto que resulta em uma versão do sistema liberada interna ou externamente. Geralmente a cada nova versão há uma melhora incremental sobre a iteração anterior.

A seguir serão descritas as fases utilizadas pelo RUP.

 

2.2.1     As Quatro Fases

No RUP, uma fase é o tempo decorrido entre dois marcos, em que os gerentes tomam decisões importantes, sobre se prosseguem com o desenvolvimento e, caso isto ocorra, o que é necessário em relação ao escopo, orçamento e cronograma do projeto.

A seguir será apresentada uma breve descrição dos principais aspectos de cada fase.

Concepção: Segundo Scott (2003), o objetivo fundamental dessa fase é estabelecer a análise econômica do sistema proposto, na versão inicial funciona como uma justificativa para comprometer-se com o projeto de desenvolvimento. As versões posteriores justificam a continuidade do projeto. Os passos chaves para se chegar a esse objetivo são:

                Definir escopo

                Esboçar arquitetura candidata

                Identificar riscos

                Iniciar análise econômica do projeto

  • Elaboração: Segundo Scott (2003), os principais objetivos dessa fase são capturar a maioria dos requisitos funcionais restantes e estabelecer uma base arquitetônica para o desenvolvimento futuro, expandir e refinar a análise econômica do sistema além de tratar questões envolvendo orçamento e cronograma. Os passos chaves para se chegar a esse objetivo são:
    • Capturar a maioria dos requisitos funcionais
    • Expandir arquitetura candidata em uma base arquitetônica;
    • Tirar o foco dos riscos críticos, que devem ter sido vistos anteriormente e abordar riscos significativos, que podem influenciar no cronograma e no orçamento;
    • Especificar os níveis de qualidade que o sistema deve atingir em relação aos requisitos não funcionais.
    • Incorporar a análise econômica e o plano de projeto detalhando ainda mais os custos e o cronograma.
  • Construção: Segundo Scott (2003), o principal objetivo dessa fase é construir uma versão operacional do sistema, que possa ser entregue a clientes, enquanto a equipe continua trabalhando para atenuar possíveis ameaças a essa entrega. Os passos chaves para se chegar a esse objetivo são:
    • Concluir o modelo de casos de uso;
    • Concluir os outros modelos: análise, instalação, projeto, teste e implementação;
    • Garantir que o sistema disponibilizado reflita a intenção especificada na descrição da arquitetura;
    • Monitorar os riscos críticos, os significativos, e tomar as medidas necessárias para atenuá-los, conforme vão se concretizando.
  • Transição: Segundo Scott (2003), o principal objetivo dessa fase é entregar uma versão operacional a alguns clientes betas, e futuramente a todos os clientes, enquanto se continua a resolver possíveis defeitos encontrados por estes clientes betas, bem como analisar e avaliar sugestões de funcionalidades que não se qualificam como defeitos. Os passos chaves para se chegar a esse objetivo são:
    • Preparar a divulgação do sistema;
    • Preparar a documentação necessária para os clientes betas;
    • Divulgar o sistema;
    • Ajustar o software de acordo com as necessidades necessárias para acertar as diferenças em ambientes de cliente.
    • Coletar informações sobre defeitos e fazer correções planejadas.

2.2.2     Os 5 Workflows

Cada workflow é um conjunto de atividades que os membros do projeto executam. A seguir será dada uma breve descrição sobre cada um dos workflows.

  • Requisitos: as atividades do workflow de requisitos objetivam construir um modelo de caso de uso que forneça os requisitos funcionais do sistema que está sendo definido, isso envolve capturar requisitos de todos os interessados no projeto até que o cliente e a equipe de desenvolvimento concordem sobre as capacidades do sistema e as condições que ele deve satisfazer. (SCOTT, 2003)
  • Análise: as atividades do workflow de análise visam construir um modelo de análise com o intuito de ajudar os desenvolvedores a refinar e estruturar os requisitos funcionais capturados no modelo de casos de uso, ele contém realizações de trabalho de projeto e implementação mais apropriados que os casos de uso. (SCOTT, 2003)
  • Projeto: as atividades do workflow de análise objetivam construir um modelo de projeto que descreve as realizações físicas dos casos de uso a partir do modelo de casos de uso e do conteúdo do modelo de análise, ele serve como uma abstração do modelo de implementação, além de focar também no modelo de instalação, que é o modelo que define a organização física do sistema, em termos computacionais. (SCOTT, 2003)
  • Implementação: as atividades do workflow de implementação visam construir um modelo que descrever como os elementos do modelo do projeto, como bibliotecas de ligações dinâmicas, arquivos de código fontes e componentes executáveis, são empacotados em componentes de software. (SCOTT, 2003)
  • Testes: as atividades do workflow de teste objetivam a construção de um modelo que descreve como os testes de sistema e de integração exercitaram componentes executáveis a partir do modelo de implementação, esse modelo também descreve como serão realizados estes testes bem como os testes de unidade. Muitas vezes os modelos de testes são derivados diretamente dos casos de uso. No modelo de testes estão contidos os resultados de todos os níveis de testes. (SCOTT, 2003)

  

  

  

  

  

  

2.3  UML

O padrão de modelagem de sistemas utilizado no projeto foi o UML (Unified Modeling Language).

Segundo Guedes (2007), a UML é uma linguagem visual utilizada para modelar sistemas computacionais por meio do paradigma de orientação a objetos. É uma linguagem que se tornou uma linguagem padrão de modelagem de software adotada por indústrias de engenharia de software.

O objetivo da UML é auxiliar os engenheiros de software a definir os requisitos, o comportamento, a estrutura lógica, a dinâmica do processo e inclusive a necessidade física em relação ao equipamento sobre o qual o sistema deverá ser implantado.

Conforme descrito por Booch (2000) a UML é uma linguagem gráfica que representa tudo, a documentação, a visualização e a construção de um sistema.

 

  

2.4 Usabilidade Interface Humana Computador

De acordo com a norma ISO 9241-11, a usabilidade é a eficiência, eficácia e satisfação com a qual o público de um produto, ou serviço, alcança seus objetivos em um ambiente específico.

  • Eficácia: Refere-se à exatidão e completude de como os usuários atingem os objetivos específicos.
  • Eficiência: São os recursos gastos para se obter eficácia, recursos estes que podem ser de tempo, dinheiro ou produtividade.
  • Satisfação: Refere-se ao conforto e a aceitação de uso dentro do sistema.

Segundo Nielsen (1993), a usabilidade tem como objetivo elaborar interfaces capazes de permitir uma interação fácil, agradável, com eficácia e eficiência. Deve ainda capacitar a criação de interfaces que proporcionem ao usuário pleno controle do ambiente sem se tornar um obstáculo durante a interação.

A usabilidade pode ser dividida em cinco critérios básicos (NIELSEN, 1993):

  • Intuitividade: O sistema deve apresentar facilidade de uso permitindo que, mesmo um usuário sem experiência, seja capaz de produzir algum trabalho satisfatoriamente.
  • Eficiência: O sistema deve ser eficiente em seu desempenho apresentando um alto nível de produtividade.
  • Memorização: Suas telas devem apresentar facilidade de memorização permitindo que usuários ocasionais consigam utilizá-lo mesmo depois de um longo intervalo de tempo.
  • Erro: A quantidade de erros apresentados pelo sistema deve ser o mais reduzido possível, além disso, eles devem apresentar soluções simples e rápidas mesmo para usuários iniciantes. Erros graves ou sem solução não podem ocorrer.
  • Satisfação: O sistema deve agradar ao usuário, sejam eles iniciantes ou avançados, permitindo uma interação agradável.

Nielsen (2009), afirma que num sistema ideal o objetivo é deixar o usuário o mais a vontade possível, ele deve ser capaz de usar a ferramenta para a tarefa determinada e não adequar a tarefa à ferramenta.

2.5  Coletando Informações

Nesta fase do projeto, foi feita uma análise entre os colaboradores do grupo e a partir dela foi elaborado um questionário de entrevista para os principais usuários do Sistema da Empresa SIMP e com ele pode-se chegar ao levantamento dos casos de uso (Esse questionário encontra-se nos apêndices).

2.6  Conclusão

Pode-se concluir que ao final deste projeto as expectativas foram alcançadas e todos os objetivos cumpridos com sucesso. O Sistema S.C.O.S é um sistema que oferece ainda que limitada uma interface com o cliente final da Empresa SIMP, que também se manifestou satisfeita quanto a realização do mesmo e do empenho do Grupo do Projeto.

Há certamente muitas outras funcionalidades importantes que devem ser atribuídas ao Sistema, como o controle e gerenciamento de outros departamentos (RH, Estoque, Administração e etc), o gerenciamento de relatórios e controle de cópias/impressões. Contudo todas essas possibilidades serão analisadas e posteriormente desenvolvidas em equipe.

O sistema se mostrou de fácil navegabilidade e interatividade com o usuário e conseguiu atingir o objetivo de criar mais um canal de comunicação para o cliente final da empresa SIMP no momento que este precisar de assistência técnica ao seu equipamento.

Todo o Conhecimento aplicado no projeto veio agregar mais conhecimento ao grupo que estudará a possibilidade para novas implementações e upgrades do Sistema.

 

Referências

 

BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro:  Elsevier,2002.

BOOCH, Grady et al. UML: Guia do Usuário. Rio de Janeiro: Campus, 2000.

CARVALHO, Ariadne M. B. R.; CHIOSSI, Thelma C. S. Introdução à Engenharia de Software. São Paulo: Unicamp, 2001.

FOWLER, Martin. UML essencial: um breve guia para a linguagem-padrão de

GUEDES, Gillians T. A. UML- Uma Abordagem Prática. São Paulo: Novatec, 2007.

Guedes, Gillians T. A. UML2 – Guia Prático. Novatec: São Paulo, 2008.

http://www.codefutures.com/data-access-object/ (acesso no dia 15/11/11).

PRESSMAN, ROGER S. Engenharia de Software- (6ª edição), São Paulo, Ed. McGrawHill, 2006.

Ramos, R. A. Treinamento Prático em Uml. Digerati Books: São Paulo, 2006.

REZENDE, D. A. Engenharia de Software e Sistemas de Informação. Brasport: Rio de Janeiro, 2005.

RUP www.ibm.com/software/awdtools/rup acesso em 12 /09/2011

SANTOS R., Introdução a Programação Orientada a Objetos Usando Java, São Paulo, Editora Campus, 2003.

SOMMERVILLE, Ian. Engenharia de Software. Addison Wesley: São Paulo, 2003.

Download do artigo
Autor:


Artigos Relacionados


Vento

15 De Outubro

Ja Ta Na Hora

A Destinação Da Sabedoria

Mulher Ii

Poesia

Minha InfÂncia